unofficial famitone 4 is done

I had this 99% done for a few months, but was getting a bug with the nesasm3 version. Turns out that copy pasting from asm6 code to nesasm3 is dangerous. Had to do a byte by byte comparison of the output.

This little guy. lda (FT_TEMP_PTR),y
turns into lda FT_TEMP_PTR,y
and needed to be lda [FT_TEMP_PTR],y

Anyway.
Added effects 1xx,2xx,4xx. Vibrato speed is permanently set to 8. Vibrato depth is limited from 0-A. Only 1 fx column per channel. You can do 1xx(2xx) and 4xx on the same note, but the fx must be on different lines in the famitracker file.
(as with my version 3.2, also has volume column and all notes supported)


https://github.com/nesdoug/famitone4.1

(source included)
Let me know if there are any bugs.

(note)
This music engine was used in Flappy Jack (fx really only noticable on the end song ... well you can hear vibrato on the title song too), and an unfinished project that I shelved, and will be used on the upcoming Full Quiet.

I'm getting interested in this version of famitone

What I would like to know is, how do I figure out if a song is compatible or not and how do I convert it for this engine? I have some old songs that are not made by me but doesn't work with the current version. I didn't have time yet to analyze which effect are missing but will do once required.

Now that this engine exist, I may be inclined to start checking earlier for research purpose.

From famitracker, do a text export. Then drop that in the same folder as text2vol4.exe. From the command line, type "text2vol4 [filename of text]". It will give an error message, if unsupported fx are used.

Requires a famitracker file. It will not process any other kind (like nsf).

Thanks for doing this, dougeff. It looks like very useful. Also good to have a broader selection of drivers.

I believe there is a bug, possibly in every version of famitone, but I haven't looked.

If you put more than 1 D00 effect in the same frame (you won't be able to see it in famitracker, since the higher D00 will shift everything up, hiding the lower ones), it will calculate the end of the frame wrong. (possibly the lower one overwriting the upper one when text2data parses it).

Sadly, many Bothans died to bring us this information.

I don't have the time to work on this issue right now, but I thought you would like a bug warning.


***
I forgot to mention, in any of my documents, that I added a command line switch.
-allin

to prevent it from removing unused instruments. This allows you to process 1 song at a time, and cut and paste them back together later, and the instruments still match.

And another bug, if you put a Bxx effect on the same frame, below a D00 effect. In famitracker, you won't see the Bxx (the D00 will hide everything below it), but text2data WILL see the Bxx effect hidden under it, and make that the loop point.

And a 3rd bug, related to the Bxx effect, that I don't understand. (I am getting wrong instrument at the loop point, but only if Bxx effect is there).

I never touched the Dxx or Bxx effects, and I didn't write the source code, so I'm not sure how to fix these.

Nevermind the last one. I think I fixed it.

line 1103
if (chn<4) insloop[chn] = ins;

just copies the last instrument from the last pattern and saves it to insert to the loop point. Which is wrong. ie. when we loop back the loop point, we don't want to overwrite the instrument THERE with an instrument at the end of the song.

Now I have it look for the first instrument in pattern at the loop start (pos == song_original.order_loop) && (ch->instrument >= 0), and save that, once, to insloop[chn].

Need to test it some more, and plan to try to fix some more bugs before resubmitting for use.

I think I've fixed the "multiple D00" bugs (which, by the way, only triggered if the 2 D00 effects were on different rows on different channels). Need to test more.

I might add a command line switch to ignore unsupported effects, rather than fail to process altogether.

I'm working on a large project with lots of unsupported effects, and every time I'm sent an updated file I have to go line by line in the text export and remove unsupported effects.

It might be faster just to write it into the source code to ignore them.

..

Should I call the switch "-force" or "-ignore"? Or perhaps "Wno" or "Woff"? .. EDIT, went with "-Wno"

Haven't read the thread in details, but I hope it's ok for me to ask these questions - at least to get the info out there (I could research most of it myself)

1. What exactly do the supported effects do?
2. What happened to Famitone 3? Was that also an unofficial release by you?
3. How does performance and storage (of tracks) compare to Famitone 2?
4. Does the converter (text2vol4/text2data?) support converting files that use unsupported effects? It would be really nice to have the option of simply ignoring them, but with a warning that it will be ignored during conversion. It's a feature I really missed in Famitone2.

Famitone 3 added volume column and all notes.

Famitone 4 added 1xx,2xx,4xx effects. That's pitch rise, pitch fall, and vibrato.

I just put all the bug fixes and new switches in all 3 versions of famitone. 2,3, and 4, and will post them on github soon.

There is a loss of efficiency. At least 25% bigger files. More if you heavily use the volume column. I estimated the efficiency difference in the usage.txt files.

And, yes. One of the switches tells the program to ignore unsupported effects and process the song anyway.

What can I say, you're a hero.

Here, they are posted...

https://github.com/nesdoug/famitone2d

https://github.com/nesdoug/famitone3.3

https://github.com/nesdoug/famitone4.1

Will be interested in famitone 4 for my real project, that's for sure. Using a combo of famitracker/famitone is memory intensive but for now it's more than enough.

Good work

Thanks. I'm glad I could make a useful contribution to the nesdev community.

Hey!

I was trying to build a simple ROM to test this out. However, the playback doesn't seem to match what I intended.
Specifically, seems like noise arpeggio sequences and volume column sequences on both noise and pulse channels sound kinda weird.

Maybe I'm missing something obvious here, but any help is appreciated
I am assuming it is possible to use volume envelopes and the volume column at the same time, right?

Although it's not stated in the readme... I believe arpeggio sequences have to be "absolute" and not "relative".

Sounds ok when I process it, with "absolute". Not sure what you're doing different that the volumes don't sound right. Are you using the newest versions of the famitone 4 asm code and the newest text2vol4?

(this is a test file that I gutted and put your song in, don't touch any buttons, they won't do anything usefull).

Ah, noted! That still didn't seem to fix it for me, unfortunately :/

It does, indeed! That's intriguing...
Maybe I just didn't assemble the files correctly? I'm not super familiar with ld65, but the cfg file I was using seemed to work.

Yes, I'm using the version linked previously on this very thread! Weird...
Oh... now that I think about it, I am running text2vol4 through Wine, since I'm on Linux... maybe that's the source of conversion errors?
I'm including the Song.s file I generated so we can hopefully compare them.
Thank you for the help, btw. This seems like it could very well be one of the best sound engines to use right now, as it would make composing considerably more straightforward for someone used to " normal " Famitracker

I'm getting different data. I don't know why. My Song.s looks somewhat different.

Use the files from the github, if you aren't.

I re-downloaded the files just to be sure, but, alas, still the same issue.

Wine gives me a bunch of errors when running text2vol4, but since it still outputs the files, I assumed it was working properly.
Unfortunately, seems like it must use some API call Wine doesn't implement or something. Oh, well... guess I'll have to awaken my Windows VM.
Any chance of a Python converter happening?

Thanks for trying to figure this out with me

@Thecoolestnerdguy

Since text2vol4 is a cpp it could be compiled on other platforms (I did it once for famitone 2) but right now I did a quick test and stdafx.h is missing and it uses conio.h too, both are usually windows specific (conio is ms-dos specific) so to make it work on linux it requires a little bit of work. I could always re-test it again and adapt it for other platforms.

@dougeff

What is included in stdafx.h?

stdafx.h

That's just something Visual Studio uses to speed up compiling. Remove it if you like.

@Thecoolestnerdguy

If you remove conio.h, which is not used in that file and change the top with this:



it should now compile on linux. It should compile on mac too.

Indeed, it does!
Its output seems to match the one generated by the Windows executable, while being a bit smaller, somehow..? Maybe that's just down to Windows handling .txt files differently?

Either way, the problem with playback still persists :/

@dougeff, can you send my the Song.s file you generated so I can test whether the issue is somewhere else in my build process?

I don't know why your computer isn't outputting correctly.

It it's a formatting bug it could be some locale that impact how the data is parsed (this is a very far fetched guess but possible).

I think there is a file that you did that is supposedly fine so I could try to do a diff with my linux box to see if there is any difference. If not, then something is influencing the conversion in some way on his machine, somehow.

edit:

@dougeff
it's not in the thread. If you could include your result data I could test it against a version on my linux box to see if there result is the same.

Sorry for the delay.

I double checked. You data IS the same as mine. The only difference that I see besides changing the arpeggio to "absolute" I also changed the arpeggio sequence to match the original...

so the instrument definition (closed hat) are slightly different, due to my changes in famitracker.

mine...

@env4:
.byte $c1,$c2,$c4,$00,$02

yours...

@env4:
.byte $c1,$c1,$c0,$00,$02

The rest of the data is the same.

The word "FamiTone4.1" at the top is different in the linux version. I changed it to just say "FamiTone4" so that I don't have to edit this line every time I do an update. Which tells me that the linux version is an older version of text2vol4.

So, whatever "Song_win.s" was made with seems to be correct. Use that.

ok! No need to test then

Maybe we could check later how to make them easy to compile on multiple platform. That was one issue with the original version and I think it doesn't require much, like the quick edit I shared yesterday. I have access to 3 platform (win/mac/linux) so I could test all of them.

How to compile could be explained in the file directly or a simple makeFile could do the job too. But it's not that difficult, just g++ nameOfFile.cpp -o nameOfFile does the job so maybe there is no need for a makeFile after all. Or it could be useful to compile all of them in 1 shot.

Song_win.s was generated using the text2vol4 Windows executable that is on GitHub through Wine. The Linux version is from the native binary I compiled making the changes @Banshaku suggested.

Nice!
I guess that isolates the issue down to something with my code, then... Well, I'll have to figure it out.
Thanks for the help, y'all

I don't know if anyone would be interested, but I made a map of every famitone variable.

https://github.com/nesdoug/famitone2d/b ... mitone.txt

I did this because I plan to port famitone2 to gameboy. This was part of me trying to understand the code better.

version 5.0 is done. (ca65 is... I still need to make asm6 and nesasm versions)

1xx,2xx,3xx,4xx,Qxx,Rxx effects
duty cycle envelopes
sound fx >256 bytes

https://github.com/nesdoug/famitone5.0?files=1

I added PAL support on my versions of famitone 2,3,4.

And added some conditional statements that will only affect you if you ONLY need NTSC or ONLY PAL.

And also edited the vibrato to rate 6 (was 8 before)...and corrected the depth...which adds a few more bytes, but (I think) sounds a little nicer.

NOTICE...

In my famitone 4 (and probably 3 and 5) there is a song breaking, game crashing bug.

My encoder produces wrong code for a note cut in the DPCM channel, which I apparently never thought to test.

I will attempt to fix at my next free time.

(probably more potential bugs exist in famitone 5, but I haven't had a chance to test it thoroughly)