tokumaru wrote:How exactly do 4-byte instruments work? Can an instrument do anything without a macro? The "macros" you're talking about are what Famitracker calls "sequences"?
I guess "macro" was a term picked up from PPMCK/MML, but yes it is synonymous with "sequence" in Famitracker. I also often call them envelopes. Sorry if this is confusing.
Yes, an instrument is just a selection of macros. One for each of the type of envelopes you can assign. (Famitracker actually has 5 envelope types, but "hi pitch" is not very useful; other data can be associated with an instrument, too, but it's not very essential.)
tokumaru wrote:Couldn't I just write some slide macros with the few combinations of offsets and speeds I need? I know that's not nearly as efficient space-wise, but as long as I don't need many combinations of offsets and speeds, I think this could work.
Depends on how much you want to use it. A few real problems:
1. Every interval is a different distance for each starting pitch, so if you use an envelope to make a slide from C-3 to E-3, you can't really use it for any other pair of pitches.
2. Determining the precise values needed for a targeted slide envelope is tedious.
3. Slow pitch slides require very large envelopes.
4. The pitch slide effects all have configurable speed; each envelope only supports one speed.
If you want to do it rarely, sure, it's fine to create a couple of special instruments for specific slides. If you want to do it often, no, it's not really feasible without dedicated code.
Again, though, if you don't have this feature you just compose around it. You can still do plenty of pitch effects, it's just difficult to do a targeted slide from one precise pitch to another without implementing the effect.
There are other ways to handle pitch, too. You could create an expanded pitch table with 16 divisions of each semitone (like how MODs do fine pitch), allowing pitch envelopes to apply logarithmically so you could make a "5 semitone slide" envelope that could be used on any note of the scale. This is feasible from an engine perspective, but it's not compatible with Famitracker's linear model of pitch.
tokumaru wrote:The playback code is simpler, I guess, since the code for processing envelopes is already there for instruments, and could be reused for these effects.
I think the biggest problem with effects, is that each class of related effects requires RAM to maintain its state; this is true whether or not you try to implement it as an envelope. The actual code complexity of an individual effect tends to be pretty small, the inefficiency is usually just due to having to implement a collection of them. Each effect is one more bit of state you have to track and update every frame, multiplied by the number of channels that effect may apply to.
I was saying that it's true that a few of the effects could in theory be implemented by reusing other envelope code, but in general I think the extra envelope data would end up being bigger than the code you saved, and RAM usage would be the same or worse. CPU for any given effect is probably similar or better than an envelope. In some cases it could just be an approximation of the effect too. I understand the train of thought but I don't think there's much to gain here. The complexity of the
effect code is not really the problem with effects, and probably not worth trying to "simplify" by replacing with extra envelopes.
The thing is, though, the set of 4 base envelopes that an instrument has (volume, pitch, arpeggio, duty) are very versatile as-is, easy to use, and they can all operate with the same code. As I said, you can just make vibrato as an envelope that's part of an instrument; you don't require an effect feature to add it. There's a lot of functional redundancy in what Famitracker's effects do; they're just there to support different workflows and make it easier to produce music. This is why my answer to your OP question was that you don't really need effects; you've got tons of functionality already with just the 4 envelopes.
You could do something like let a vibrato effect
replace an instrument's pitch envelope if it's blank, rather than acting as an overlaid thing. That way the effect isn't actually doing more runtime work, just a 1-time setup thing, but if you do stuff like that it starts to get really divergent from how something works/sounds in Famitracker. I dunno how much you want to go down the road of either modifying Famitracker, or giving your composer features they can only hear if they do an export and run in an emulator, but in general I'd avoid this.
My approach was just to pick a flexible/versatile subset of features from Famitracker; I didn't really want to do stuff that Famitracker couldn't, even if that seemed convenient, because I wanted it to sound exactly the same in the tool as in the game, and to have no confusion about what's going to happen. Anything that's not supported throws an error during export, and everything that is supported should work identically, as much as it can. (I did make a few subtle differences.)