nesdev.com

Hi, from the famitone2 readme:
- No volume column support
- Only Volume, Arpeggio, and Pitch sequences (no Pitch for noise channel) supported
I understand the 1st row, but don't understand the 2nd row.
Can I change the volume of a channel? (and if yes, how?)

The second line refers to instrument settings. You can set volume envelopes per-instrument and it will work with Famitone. This is the only way to change volume with Famitone.

I wrote a version of famitone that
-has a volume column
-has the full note range

It still has a bug (processing multiple files at once), but it works if I process one song at a time, and do some other work-arounds.

One day, I'll debug it, and recompile it.

viewtopic.php?f=6&t=15096&start=0

_________________
nesdoug.com -- blog/tutorial on programming for the NES

If you're not locked into using FamiTone2 yet, you could try Pently, which supports volume column levels 4, 8, C, and F.

A word of reassurance is that there's nothing the volume column does that the instruments' volume envelope can't, because volume changes in instruments doesn't get finer with a lower "master volume". The bit depth isn't enough to cover such minute changes. Attaching example file of that.

It's mostly a convenience for the composer, and might save you some space depending on the makeup of the composition.

For space saving purposes (lesser number of instruments + lean volume column) pently is perfect

_________________
http://www.frankengraphics.com - personal NES blog

Technically you can control the volume only through volume envelopes, yes, but compared to having a separate volume column it's:

• 1. Tedious to use for that.
• 2. Creates more data via redundant volume envelopes.
• 3. Creates even more data via redundant instrument definitions.

The fact that it's a "coarse" adjustment is mostly an unimportant detail to me, but being able to play the same instrument at different volumes is CRUCIAL.

It's possible to do without (e.g. Kulor's Alter Ego soundtrack does a very good job with that limitation) and I think most commercial NES game engines did not have this feature, but its absence seems to consistently be the first thing people notice about Famitone's limitations. It's just such a useful thing to have, and fussing with a bunch of extra envelopes is not a very good substitute.

Hm.. maybe the first statement (the one you quoted) was a bit cocksure. Else, I don't think i was saying anything that goes against these three points, but now that they're brought up, i feel i have some experiences which challenge them a bit.

The prospect of saving on song size may differ from composition to composition, and from engine to engine. If you have a lot of songs and/or long songs, those volume columns just might add up and eat more space than a select number instruments played at varying amplitudes would.

It also depends on how varied your orchestration is throughout the total soundtrack. If you have lots and lots of instruments requiring lots of dynamic variation each, then that's a potential size problem. If instruments are reused between songs and channels, that's better. I think the trick here is to be sensible with what envelopes are needed to express your song(s). Some few of my instruments have 6-8 volume variations. Others have 1, 2 or 3. Echo variations are sometimes reused as other instruments for more quiet parts. Then again, by the sound of it, it seems i'm a bit more conservative than Kulor; listening to track 4 (classic). That one sounds daring and exiting and seems to explode sometimes in a way i rarely dare.


On drivers:
With pentlys' compromise, you kind of get the best slices out of two different pies. A lean volume column which greatly reduces the need of extra envelopes and instrument setups and offers some more creative freedom/convenience, albeit not as finely detailed as the native FT driver.

Another approach is having a hypothetical driver reuse parts the same envelopes by looking up different starting, looping and ending points in one long concatenated sequence; and maybe even jumping points if needed/rational. You can shave off a great deal of excess envelope data with some proper organization that way.


It's not as straightforward as simply using the volume column, i'll admit - but at the same time i wouldn't describe it as tedious. I find it rather easy, so it leads me to think this may be a different experience from person to person. I think what i do is that once i have the instruments set up, i just kind of automatically memorize what instrument number correlates to what volume setting.

Even so, it may be that i would've dared to be more dynamic with the use of a volume column for those songs i've written without one.


AFAIK, it's the only substitute short of a pently-style compromise, and the limitation it imposes is
1)mental - meaning you can rise above if you're intent on taking advantage of the full dynamic palette frequently.
2)size-oriented - which at least to some extent is circumstantial.

Then there's special cases. If you need cycle consistency, pubby's engine is the best option, and then you won't have volume columns.

In the end, at least it's an option, it's not too bad especially when you get used to it, and it just might be someones' cup of tea.

_________________
http://www.frankengraphics.com - personal NES blog

Well, if you want to know what I use it for, here's the frequent fliers for me:

• 1. Very good for instrument reuse across a whole soundtrack, and even for different sections of one tune. You might make a nice bell curve envelope, but it's going to require a different balance when you move it to a different context. The alternative is to have several curves at different volumes (or build everything else around this lack of control).
• 2. Putting an expressive taper on a voice that is entering or exiting.
• 3. Putting an emphasis or de-emphasis on one note in the middle of a line, or shaping the envelope of one note.
• 4. Dropping volume for an "echo" concept, sometimes on a separate channel but also often inline to echo the end of a phrase.

IIRC Famitone has a "lightweight" 1-byte instrument change event for the first 16 instruments, and after that it doubles to 2. As a design choice that's actively discouraging using extra instruments for volume as well. I think a lot more mileage could be had from a lightweight volume switch, personally (and that's what I implemented in my own engine).

BTW the next thing Famitracker users tend to notice about Famitone is usually a lack of duty envelopes, then the lack of vibrato or other pitch effects. Of these things, the vibrato is the only one where I find envelopes to be a relatively easy to use substitute. Same with the arpeggio effect, which is even more trivial to duplicate with envelopes.

So... sometimes I think a substitute like that is good, and sometimes I don't. With volumes, no I think it's rather terrible. The better coping method for this is to do without, and just orchestrate as if everything is a harpsichord (vs a piano), rather than use envelopes as a substitute.


I can't speak to how Pently or GGsound etc. does these things. I've used Famitone several times for various reasons, and wrote my own engine other times, plus a few miscellaneous experiments with other stuff. (My game's music engine will eventually be made open source after my game releases, if anyone wants "rainwarrior's favourite subset of Famitracker" instead of "Shiru's favourite subset of Famitracker." .) My own feeling is that an engine that is structurally based on Famitracker will have a lot more utility than going your own way and "converting" from it, though; it's just such a powerful and well used tool, with a pretty practical data design (even though there are many other valid ways to design that data).


Aside: Kulor also released the FTMs for that soundtrack I linked above, in case anyone's curious: http://famitracker.com/forum/posts.php?id=2761

The soundtrack i'm (still) working on for the zeldaesque topdown screens i shared earlier this fall is going to be an odd duck, because that driver isn't published nor finished. Basically the plan assumes that the instruments are sorted prior to export to accommodate for the drivers' way of jumping both instruments and notes relative to the last one, so that the data needed for each instrument shift can be kept as small in size as possible. My other case where i don't use the volume column is meant for pubby's engine, though i'm not sure yet if i got it all right.

I tend to not look at famitone because i like a bit more freedom with sequencing duty changes on some instruments and don't really want to part with that option, so i can't really comment if it's efficient size-wise. But my largest project file contains $3E instruments as of now and i switch them rather often, so that would lean towards "not so much", probably.


Just sometimes, you might actually get better control if you write those curves, because it is likely going to get squashed when you lower the fader, so to speak. It might sound just the way you want it to (that squashing is what you'd do anyway by hand, many times), but there may be cases where you want to fine-tune the curve at some other volume setting.

For what little i've done FT music with the volume channel, i use techniques 2, 3, and 4 all the time.

Another very frequent use of the volume channel is when the same instrument is used in duo on the squares, it oftentimes becomes a lot more pleasant if one channel is just a smidge weaker than the other, and it feels more alive if you play around with which note in the duo (upper or lower) is stronger and which is weaker. This is true for two different instruments too, but more acutely so when they're the same.

It's a bit like 3, but the focus is balancing the blend of timbre between two channels rather than rythm accentuation on one channel.



Even if you'd go this route in a project where you had no choice (because a driver was developed or chosen for other reasons than composing/musical preference), there's still little tricks to be had. anything between exponential and linear swelling curves will sound more quiet when played rapidly because they won't have the time to build up, and dropping bell slopes and linear slopes will sound more dense and droning because they don't have time to land, while highly de/accelerating curves won't have as much of an effect. Since a selection of different curves like this is likely to be in any projects' list of envelopes, they might as well be used to that effect consciously.

_________________
http://www.frankengraphics.com - personal NES blog

Over the last 10 years of using Famitracker, no, not really. The "squashing" is not a significant problem, and the versatility of the volume column is immense. I can't put these on comparable footing at all. I'm completely aware with how the volume affects envelope precision, and it's exactly what I want it to do.

When Famitracker went from a subtractive volume column implementation to its current pseudo-multiply was a turning point in this, though. The subtractive version was NOT exactly what I wanted it to do.

If I want to make a different instrument for a quiet part, that does happen, but its never been in response to the "squashed" envelope precision from using the volume column.


This is basically exactly what I dislike about composing for C64. You don't have volume, not even at the envelope level, so all you can do is work around it.


Like if you really got down to it about which features I find important for composing, I'd probably rank a volume column higher than pretty much every control? More than vibrato/pitch envelopes for sure. More than duty. Maybe even more important to me than the volume envelope itself... though this is clearly the reverse of shiru's priority and many other people's who omitted it.

I agree that the volume column is very important.

At some point, though, the question becomes "why not use the full famitracker driver"? Shiru's version.

I think ir might be because it hasn't been rewritten for their preferred assembler yet.

Size is another problem. Adding a volume column adds a byte per volume change. That could amount to 1000 extra bytes (3 channels * 20 per section *10 sections per song *4 songs = 2400 bytes).

_________________
nesdoug.com -- blog/tutorial on programming for the NES

Size is a problem, especially if you're trying to make an NROM project or fit the replayer in the fixed bank so that it can access music data in multiple banks. FamiTracker uses more ROM and RAM than game-oriented replayers. In another post, I ran the numbers: 5.5K vs. 2K.

The main reason is 'cause it's 5k of code and doesn't have a sound effect system. (There's a lot that can be removed or optimized, but basically it was never written to be minimal/compact for games, and Famitone was.)


An instrument change is at least a byte too, though, this is a wash.

The real way to save size is just have less notes, less volume changes, less instrument changes, more reuse of things, etc. but that's orthogonal to the volume column inclusion, IMO. (256 bytes for the pseudo-multiply table is not orthogonal to it, however. That's significant-- though you could probably replace it with <30 bytes of slower 4-bit multiply code?)

I should perhaps have said that i didn't really mean it as an either or case here. If the driver doesn't have a volume column, you have to make do. But if you have it at your disposal, you can, however it is in your preference or not, overlap both techniques as you see fit. Given the versatility of the volume column, i totally get that these pockets are slim and that it's a light decision simply not to use it. Anyway, with the volume column in place, i think extra envelopes can still add these to the composition, if one feels the need:
1)lower and truncate the envelope (it falls silent earlier). I guess this is the subtractive behaviour you didn't like in the first place. I seem to mostly use this on hihats, and just sometimes little "tink" sounds, honestly.
2)squash it disproportionately close to the bottom, rather than evenly. A compromise between (1) and even squashing. Produces a thinner sound without losing all sustain. Doubles as a setting for brighter piano/string notes.
3)squash it disproportionately at the peak, rather than evenly (this simulates compression in order to let some other channels' peaks shine through better momentarily without losing body, but can also be used for instruments that are supposed to play softer. volume envelope generally does that job ok too).
4)i sometimes do little "puff" and "breath" instruments which lower and raise the volume and goes back to normal mid-note quicker than i could control from the volume envelope, unless one tick = one step.
5)slight companding, to accentuate rythm over body for certain notes or parts. I've admittedly never done this in FT consciously with companding in mind, but it should work.

So yeah, ransacking myself, precision isn't really tied to what bits are lit or not when fading, but rather what physical instrument i'm trying to approximate (if any, but that's usually the case) or what the mix "demands".


Just curious... Is that desert island choice assuming a vibrato/pitch effect is in place or not?


And of course, ~5k would be monstrous if you did it like metroid and had several copies of the music driver in different banks.

_________________
http://www.frankengraphics.com - personal NES blog

Another limitation of the famitone system, that I personally found a bit annoying, is... it interprets any volume of zero, in a volume envelope, as the end of the note...and simply erases any part of the envelope beyond that.

I had to use volume of 1 for mid-envelope silence, which is still noticeable some times.

(Slight edit)

Inaccurate.

_________________
nesdoug.com -- blog/tutorial on programming for the NES