DRW wrote:Is a volume envelope supposed to have the same sequence of volume values for each note throughout the whole song?
In Famitracker you can change instruments as often as you like. You can tell your composer they can only use one instrument, if you want, but that's pretty restrictive.
DRW wrote:Does the next note's volume start from the beginning?
Yes.
DRW wrote:And if a note is too long? Does it simply set the first volume after reaching the last?
Macros envelopes usually have a loop point. If no loop is specified, you can just loop on the end of it.
DRW wrote:Why isn't ( arpeggio ) possible with my attempt? Simply set the length to 1, then store the notes.
The data for doing this becomes very large very quickly. (This principle applies to all use of envelopes.) An instrument would store the arpeggio in a couple of bytes, and it be applied to a thousand notes at no extra cost.
DRW wrote:Isn't it a huge performance hit when your music engine has to go through 20 envelopes and adjust each note according to these values?
It takes CPU time, but it doesn't necessarily take a lot of it.
DRW wrote:Also, what happens when two values clash?
You'd have to be specific, as I think each type of envelope is applied differently.
DRW wrote:Say you have a volume envelope, but you can also change the volume mid-song. What happens then? Which value does the program take?
Specifically Famitracker multiplies the volume column value with the volume envelope value (rounding up to 1 if nonzero). (Table lookup implementation.)
You're asking a lot of questions about how Famitracker works. This dialogue is really not a very good way for you to get this information, though. A lot of this would probably very quickly become clear if you read Famitracker's documentation or followed
a tutorial, or read its
wiki. Actually using the program will explain this better than asking me sparse questions about its implementation.
DRW wrote:But this would also require to go through the whole song manually and painstakingly check what could be created with a macro, right? Or intensively studying the Famitracker to get to know each and every feature.
No, if you want to use Famitracker's features, you should not try to reverse detect them from a register write log. You should just take the exported data as Famitracker produces it. You can check right there if any effects are used, and warn the composer if anything you don't support it used. You don't have to try and detect envelope macros from register logs, instrument definitions are right there in the exported data.
DRW wrote:So, how about just using the Famitracker library in my program and letting the composer do whatever he wants? Would this be an option?
Especially: Is that code quick enough? I don't need a sound library that takes one third of my frame update time to do the background music.
And how much space would this plus the soundtrack occupy? (My ROM is supposed to be 32 + 8 KB.)
Its base size is about 5k. If you went through it carefully you could probably trim a lot of stuff you don't need. I can't possibly tell you how much space your soundtrack would occupy. Depends on how much music you make for it.
I don't know what your performance requirements are, here's what it says in its readme.txt:
Famitracker NSF driver 0.4.6 readme.txt wrote:Average CPU usage is somewhere between 1200-2000 cycles (4-6% of a video frame)
depending on the complexity of the song. Peak usage is higher, usually between
10-15% when switching patterns. This might be improved in future versions.
The main thing that Famitracker is lacking for use in games is sound effect overrides. You'll need to handle that yourself.
Alternatively, you can just use Famitone2, which takes Famitracker music files and turns them into its own format. Famitone2 only implements a subset of Famitracker features and your composer would need to know exactly what's missing. Its biggest missing feature is the volume column; it only has volume envelopes. (It's missing a bunch of other stuff, but that's the one that stands out for most people.)
There's also Muse Tracker. I don't know much about it, but I believe it is well featured and does have a sound effects feature. Famitone2 seems to be more popular, but that might have more to do with all the tutorial stuff Shiru has written than its feature set.
Stepping back a bit, there's other ways to implement some of these concepts; you're asking specifically about Famitracker, and if your composer is using Famitracker you might as well just implement things that work the same way. That's one of Famitone2's problems; it's not really based on a subset of Famitracker, it's just that a lot of it was similar enough to what Famitracker does that Shiru could translate Famitracker tunes into Famitone2 data (as long as the composer doesn't try stuff that would expose the differences); many things about it are fundamentally different than Famitracker's implementation though (e.g. how it handles pitch).
If you look at other NES music engines, you'll find all sorts of ways of doing things. As I mentioned, almost all of them have something that works like a volume envelope macro, but other than that, all bets are off, pretty much. Famitracker has a very versatile set of features, and just the 4 envelope types I mentioned are extremely powerful together, but lots of engines don't have pitch/arpeggio/duty envelopes.
My own approach was to write my own engine that worked fundamentally the same as Famitracker, just as a strict subset. That way there aren't surprises when I am exporting, everything that can be exported sounds and works the same, and everything that can't gives me a warning/error on export.
One of the things that you can't do well with envelopes is sliding pitches between notes; I can't think of an commercial NES games that do this, but Famitracker's pitch slide effects (e.g. Qxx/Rxx/3xx) are very expressive, and well liked by Famitracker composers.