jrlepage discovered this; only a problem on hardware because emulators don't account for it, but the VRC7 custom patch loading code (which is in instrument.s instead of vrc7.s) does not have a sufficient delay between writing $9010 and $9030, so the custom patch registers tend not to get set properly.
After sticking a pair of jsr ft_vrc7_delay lines into intrument.s, it runs fine on jrlepage's machine.
Additionally, it might be prudent to put in a register init for the VRC7 at (i.e. write 0s to all registers) at the end of ft_music_init, since in my tests the hardware registers have not been consistently 0 on reset.
I noticed an odd thing. rainwarrior made a custom build of the 0.3.7 executable with the driver fix, and all works 100% fine on hardware. Beta 5 did indeed solve the VRC7 timing issue (thanks!), but I still get another issue I had with other versions, which is that sometimes the 2A03 squares' duty changes to 12.5% randomly.
Here's a comparison between the correct export and the incorrect one. You can also download the correct NSF and the incorrect one, if you need to, as well as the FTM.
I don't know to what degree an issue I'm having is related to this one, but it is a VRC7 custom patch-related bug, so I might as well bring it up here.
A while back I made this FTM that uses custom VRC7 patches. Track #1, Anubis, sounds fine in FT, but an exported NSF has some weirdness in it. Both files are attached. A slight discrepancy between the sounds of the FTM and the NSF is noticeable as early as the end of frame 02 (about the nine-second mark in the NSF), but it's much more clearly wrong at the end of frame 06 (about 29 seconds into the NSF).
I recall reading about some limitation or another regarding custom VRC7 patches, but I don't remember what it was. I figured, since it sounded fine in the tracker, it would probably export fine too.
It is notable that I exported this NSF using BETA 5 (July 16 2012).
_______________________
All men are mortal.
Socrates is a man.
Therefore, all men are Socrates.
VRC7 playback varies a lot between NSF players. NSFPlay and Famitracker are at this point pretty close (using the same VRC7 code, mostly); others may have other kinda different patch sets or emulation. (It is the least consistently emulated expansion chip.)
What are you playing the NSF in, and how are you comparing it to the FTM? If you import the FTM via NSF importer, does it sound like you expect again?
It appears that the bit you pointed to at the 29 seconds mark, it seems to be reading from default patch #14 and writing that as the default instrument. But more importantly, your bass drum patch plays completely wrong all along! Toms seem to be fine though, for some reason...
I think part of it is FamiTracker emulating the VRC7 wrong, and part of it is an issue with the exporter. The kick drum definitely sounds like that on real hardware. The shoddy fill 29 seconds in seems to be an export issue - like I said, it seems to me like it's reading custom instrument data from default patch 14, as opposed to the one you defined in the FTM. Very odd indeed.
It isn't unintentional and it's probably how the chip works, but the Carrier and the modulator seem to be in slightly different pitches all the time and there's a very slow phasing effect for certain notes, is that normal?
