I'm surprised no one has held me at gun point and forced me to do it yet. I should get crackin' on it by now.
Generally I would presume that a private message suffices :-)
But either I am just imagining, or you never sent me a reply to the second message in which I asked about the sound data.
I admit the "atoms constituting the cake" metaphor was a bit flawed. It would be a more apt description of an MP3/WAV recording of the song. But still, what a NSF player sees is in that general direction
comparing to the original data which is comparable to a cake recipe.
I just did a quick check on the NSF importer. Just what I thought: It creates a row for every single frame of the song. No instruments, no effects, no envelopes, no nothing. Just raw frequency & duty & volume data, i.e. exactly what the soundchip receives as the song plays.
It is basically exactly the same thing what I did in 1996 with NESMusa (
), except that I didn't know about dutycycles back then and the S3M format I was generating could not reproduce pitch variations in cents, and the iNES SND files I was converting didn't record DPCM samples.
You could have a NSF file that contains an infite loop that simply plays two tones in repeating sequence with a piano-type envelope for 2 minutes. This would fit in about 30 bytes of assembler code in total (of course the NSF file would be padded to 16384 bytes or so, but that is irrelevant). Then you import it into Famitracker, and you get 56 patterns of rows: a note every 16 rows and a volume change every 2 rows. Lots and lots of data.
To give you an idea what's going on.
Are you talking about the G-3 and F-2 chord. Even if you're not, I tend to put in some sharps or "sour" notes when it deals with a creepy atmosphere, in this case Simon is in a graveyard. It would help if you point the place specifically.
Pattern 8, row 1C is what I mostly meant.