Instruments vs. effects?

[tokumaru]

Guys, am I right to assume that in a sound engine with support for instruments there's not much need for effects?

I've looked through a few Famitracker soundtracks and some (simpler sounding) songs don't use any instruments, only effects, and others barely use any effects, relying mostly on instruments. Is there any real reason to mix both? Can you give me any examples?

I can see how having volume or pitch modifiers you can apply to each note can be useful, but other than that I don't see how having 20+ effects could make a significant difference in how a song sounds or how efficiently it's represented, specially considering how much more complex the engine has to be in order to support these effects.

This is my impression as a coder, since I'm not much of a musician, which is why I'm looking for more educated opinions.

[tepples]

Guys, am I right to assume that in a sound engine with support for instruments there's not much need for effects?

It depends on how versatile the instruments are and how many are allowed in one project.

I've looked through a few Famitracker soundtracks and some (simpler sounding) songs don't use any instruments, only effects, and others barely use any effects, relying mostly on instruments. Is there any real reason to mix both? Can you give me any examples?

Vibrato can be encoded as an envelope in an instrument, but portamento can't because it's different for every note. Much of the soundtrack of Haunted: Halloween '85 has volume controlled by instruments but pitch controlled by effects, especially portamento. I haven't had time to make NSF, but an audio recording is attached to this post.

Even so, you might want, say, "loud sax" and "quiet sax" without having to double up the instrument definitions.

[rainwarrior]

In my game I only implemented instruments, more or less. I thought it was enough, you can listen to decide: https://rainwarrior.bandcamp.com/album/my-lizard-is-the-lizard-of-soundtrack

It's this subset of Famitracker features:

1. Instruments with volume, duty, pitch, arpeggio macros.
2. Volume column.
3. Effect F0X to control tempo ("speed" only, no BPM).
4. Effect BXX to create a loop.
5. Effect D00 to change the length of a pattern.
6. No DPCM.


Of course, if there was something else I really wanted I would have added it. Things like portamento aren't really doable as instrument macros, for example, but I simply used the pitch macros in ways that work around this, e.g. I have "bend in" and "fall off" pitch macros that don't target definite pitches but still give a similar feel to how I might use portamento in places.

So, I mean, I totally think it's enough, but I also have a programmer's perspective. I think any decent composer can deal with what you give them, really. I mean, if they can deal with NES only having 3 melodic channels, they can deal with a few more limitations.

The more common problem, I think, is feedback to the composer about the limitations and the data sizes they're producing. You should give them tools before they start composing that can validate that they're not using forbidden effects, preview the NSF, and show them how much data what they're doing produces, so they can learn to write "small". There's probably a lot of tips you can give them on the latter, too.

[Bregalad]

Famitracker is just a particular sound engine. Other sound engine will have their own terminology to describe what FT calls "instrument" or "effect", or will use something that has no direct equivalent to FT.

Think of it like a scroll engine or a sprite engine - there's no "one way" to do it.

[FrankenGraphics]

Bit of a side note, but i've found famitracker terminology to be a little cryptic. I solder my own synths and in the synth community, we call what FT calls 'effect' a control change message, if digital (usually a MIDI CC), or voltage controlled parameter, if analogue. The term 'instrument' could perhaps be understood as a 'patch'. In fact, the track could be seen as self-patching and that would make sense, at least from my point of view.

I'm still getting to know the nes architecture, but it is my so far impression that FT wasn't primarily designed with efficient hardware playback in mind. I think the GUI has some considerable work flow related flaws, too, compared to trackers like jeskola buzz (not counting the modular part).

volume controlled by instruments but pitch controlled by effects

This is what i do, too. It wasn't a conscious choice, it just felt most convenient, i guess.

[rainwarrior]

in the synth community, we call what FT calls 'effect' a control change message, if digital (usually a MIDI CC), or voltage controlled parameter, if analogue. The term 'instrument' could perhaps be understood as a 'patch'. In fact, the track could be seen as self-patching and that would make sense, at least from my point of view.

The term "effect" is the way it was used in most trackers since they started back on the Amiga. The term "instrument" is similarly common among trackers, I think starting with FastTracker and Impulse Tracker. These really are the standard terms.

The terms you're offering come from MIDI history, kind of a completely different etymology (e.g. "patch" originally referring to modular synthesis setup). Trackers that combine stuff from the MIDI world, VST, etc. might end up conflating these sets of terms a bit, but most trackers use normal tracker terminology.

it is my so far impression that FT wasn't primarily designed with efficient hardware playback in mind

By "efficient hardware playback" I presume you mean suitable for use in a game, i.e. low CPU and RAM use.

Modules made in FT can be very well suited to efficient playback, but it's not limited to that. In particular being able to layer a bunch of effects simultaneously lowers performance and increases the required RAM use, but if you restrict yourself to a subset (like tokumaru is asking in this thread) it's actually very good for use in a game, particularly if you export to a smaller engine like Famitone, etc.

The NSF engine it provides isn't optimized for size or RAM use (it's designed to be flexible and useful, while being perfectly playable on hardware), which is why it's better to use your own, but the techniques and organization it uses for data are sensible, versatile, and relatively compact; very good for game use. If your performance/RAM budget allows for it, FT's NSF engine is really not all that bad, either, and it can be used directly in a game under the right circumstances. I think the engine size is about 5k and might peak at 5000 cycles or so; could be better, but isn't terrible. (A more lightweight engine might be 2k and 2000 cycles, for rough comparison.)


I've tried a ton of different chiptune trackers, and I'd actually say that Famitracker is the one that is the most suitable for practical use like this. What are you comparing it to? Similarly with regard to "usability", there's no other chiptune tracker that I think is easier to use, or more transparently related to the hardware implementation.

[tokumaru]

Much of the soundtrack of Haunted: Halloween '85 has volume controlled by instruments but pitch controlled by effects, especially portamento.

But in this project you were merely the coder, and had to abide by the musician's requirements, right? Would you have done anything differently if this was your own project?

an audio recording is attached to this post.

Sounds good.

Even so, you might want, say, "loud sax" and "quiet sax" without having to double up the instrument definitions.

This is what the volume column is for, right?

I thought it was enough, you can listen to decide: https://rainwarrior.bandcamp.com/album/my-lizard-is-the-lizard-of-soundtrack

Sounds complex enough to me.

1. Instruments with volume, duty, pitch, arpeggio macros.

Couldn't effects be implemented by applying another envelope on top of the basic instrument? That should allow you to modify some parameters without having to define entirely new (and mostly redundant) instruments... For example, I could create a few sequences for moving the pitch up or down a few notes and apply those on top of any instrument a sound channel may already be using, in order to have portamento with any instrument. That sounds versatile enough, even if not as compact as traditional effects.

The more common problem, I think, is feedback to the composer about the limitations and the data sizes they're producing.

Did you have to go through this or did you compose the entire Lizard soundtrack yourself?

Think of it like a scroll engine or a sprite engine - there's no "one way" to do it.

Sure, but trackers seem to be very popular, so I imagine most sound engines are influenced by them. I don't really care about the terminology, only about what it takes for an engine to be considered versatile enough to the average composer.

[rainwarrior]

Much of the soundtrack of Haunted: Halloween '85 has volume controlled by instruments but pitch controlled by effects, especially portamento.

But in this project you were merely the coder, and had to abide by the musician's requirements, right? Would you have done anything differently if this was your own project?

I was the coder for the music, and basically was given a completed soundtrack and had to port a bunch of features from Famitracker to the Famitone engine they were using.

Couldn't effects be implemented by applying another envelope on top of the basic instrument? That should allow you to modify some parameters without having to define entirely new (and mostly redundant) instruments... For example, I could create a few sequences for moving the pitch up or down a few notes and apply those on top of any instrument a sound channel may already be using, in order to have portamento with any instrument. That sounds versatile enough, even if not as compact as traditional effects.

Only some of Famitracker's effects are equivalent to instrument macros (e.g. vibrato, or fixed duty). Some aren't, like targeted pitch slides, which have to stop based on a comparison with the current pitch.

In a case like vibrato, putting an envelope on top of another envelope is equivalent to implementing the effect, as far as I see it. I don't think you're saving much by trying to think of an effect as another envelope, if anything. I'd guess it would be about the same CPU cost as FT's existing vibrato, and take up more ROM space.

In the "envelopes only" case, I would just have multiple instruments, one with a vibrato pitch macro, one with a flat pitch macro, and the other macros are shared data. An instrument definition by itself is small (a couple of bytes), and turning vibrato on and off is just a matter of switching instruments.

In mine specifically: an "instrument" is 4 bytes, and a "macro" varies but the average is 15 bytes, and macros can be shared across many instruments. I had about 3000 bytes of macros, and 700 bytes of instruments in my soundtrack.

The more common problem, I think, is feedback to the composer about the limitations and the data sizes they're producing.

Did you have to go through this or did you compose the entire Lizard soundtrack yourself?

Lizard is entirely mine, but I've gone through this kind of problem on a number of projects (not limited to NES, or music), one example of which was Haunted Halloween, as mentioned above.

If they do too much work in the dark, it's just not going to work when you turn the lights on. If you can give them the restrictions up front, but even better give them a tool they can use to validate the restrictions for themselves, you'll have less problems getting it online. I think most composers are quite willing to put up with a few arbitrary restrictions to make the implementation more efficient, but they're not happy to have to rewrite stuff they didn't realize wasn't going to work (and/or you won't be happy having to implement a bunch of extra features that could have been avoided).

Not intending to put anyone at fault on the HH project. I don't know how it ended up in that position, or how it was managed in general; I was just hired to do my part to make it work near the end of the project. I'm merely suggesting that extra limitations like "no effects" are normal rules for any game project, and artists/composers should be able to cope with them-- but only if they know about them! (...and how to validate!)

[tepples]

Much of the soundtrack of Haunted: Halloween '85 has volume controlled by instruments but pitch controlled by effects, especially portamento.

But in this project you were merely the coder, and had to abide by the musician's requirements, right? Would you have done anything differently if this was your own project?

My projects use my own music engine called Pently. I just like how it handles triangle+noise drums and loops that are shorter than a pattern. In fact, I covered most of the game's soundtrack in Pently before the musician became frustrated with the lack of portamento, despite my use of "bend in" and "fall off" instruments to make a mostly musically equivalent sequence. (Comparison)

Even so, you might want, say, "loud sax" and "quiet sax" without having to double up the instrument definitions.

This is what the volume column is for, right?

Some music engines don't have a volume column for the same reason they don't have effects: a score is expected to bake it into the instruments.

If you can give them the restrictions up front, but even better give them a tool they can use to validate the restrictions for themselves, you'll have less problems getting it online.

I learned that over the course of Haunted: Halloween '85. The level background graphics provided by the artist were hitting lots of too-many-tiles errors and attribute clash. So I took a few hours to wrap the background converter in a shell that takes an INI file listing PNG files and 32-hex-digit palette strings and write a bunch more diagnostics. As for the game's music, I made my covers along with the relevant levels, but a miscommunication between my manager and the composer made it sound like Pently itself would be extended to handle new effects.

And yes, I now plan to make a FamiTracker-to-Pently converter in case the user wants to use FamiTracker's UI (rather than Pently's native MML- and LilyPond-inspired input format) and validate a score against Pently's limits. I just couldn't do so at the time because my time was occupied with parts of the game other than music, and I can't do so now because my time is occupied with the sequel.

[RushJet1]

I tend to use a mixture of effects and instruments. Like others have said, some effects are difficult to do with just instruments (like portamento) and some are just tedious (making a new vibrato macro for every few notes depending on pitch, making new instruments for every voice/duty cycle change, etc). Though all effect commands and no instruments is just as problematic - sometimes you have a lead using a specific sound and it is tedious to have to copy/paste the duty cycle, volume, and whatever other effects manually each time.

I've written a few songs that show both extremes:

Few effect commands:
https://www.youtube.com/watch?v=WluHxbGQkBk

Only effect commands (no instruments, note that this gets super cluttered around 2:55):
https://www.youtube.com/watch?v=D6EDwXayQY4

One instrument and no effect commands (except volume):
https://www.youtube.com/watch?v=bDoIIUBmGg4

[Bregalad]

Sure, but trackers seem to be very popular, so I imagine most sound engines are influenced by them. I don't really care about the terminology, only about what it takes for an engine to be considered versatile enough to the average composer.

Trackers doesn't seem very popular in japan and that's where most games had their development done. Sound engines from games I've reversed where not influenced by trackers.

[tepples]

What was popular in Japan? MML-type things that take note names and produce hex bytecodes for the music engine? Or just entering the bytecodes manually?

[rainwarrior]

I know a lot of people from Japan who use Famitracker or other trackers. PPMCK/MML was developed there, and was documented only in Japanese for a long time, so it has a persistent regional association. Same deal with Famitracker, developed in Sweden mainly in English, has a English-speaking regional association too, but as it's become more popular it has spread to Japan quite a bit.

I don't think Japan is tracker-adverse in any particular way, it's just that for NES homebrew music, PPMCK/MML was the first really major thing on the scene.

If you're not talking about modern homebrew music, then it's a whole different kettle of fish. Doommaster1994 did some surveying of that a while back:
Forum topic 8016: How NES Music Was REALLY Composed

[FrankenGraphics]

Modules made in FT can be very well suited to efficient playback, but it's not limited to that.

I see. I was somehow getting the impression that since i could do near perfect covers of many different games with supposedly different native game engines, an engine like that, which is able to 'do it all' would be bloated, but if performance cost can be held down by restrictive use, then that's indeed very reasonable.

Regarding comparison to other trackers, my main reference is said Jeskola Buzz which is the one i've stuck with since 2004 or so, when other daw software and/or sequencers doesn't cut it, mainly because the workflow and layout is extremely good, especially in the traditional tracker part of it. Of course, it's no good for nes music. But i miss how fast and clean you can edit your song or frame or loop during playback, compared to FT.

Regarding file format, is famitone or any or all of the other engines that have been released to the community assuming that unless an instruction states otherwise, the track or frame stays the same? (for example, track 3 played frame 5, so it will play frame 5 the next frame switch, too, unless there's new data) Or is it more like 'do this for that long time'? This may not be the greatest issue, but documentation like that might be handy when composing.

[rainwarrior]

Yeah, I consider Jeskola Buzz a very unusual tracker. Definitely geared toward modular synthesis and MIDI kind of interfaces. I think its way of handling patterns is a little abnormal too, but it works fine.

Famitracker is unusual in its own ways too, but I find it works really well once you're oriented. I really do think it's the best chiptune tracker I've used; there are a lot of others at this point.


Famitracker has an "order" specified per-channel. By order, I mean a list of "patterns" to play (by number) that make up the song's order. If, for example, you want the noise channel to play a repeating drum pattern, you can enter the same number multiple times in the order.