Approximating pitch modulation with Pxx was a pain; my first thought was to sample it once per frame, but then I ran into a case where it was running at very high frequency! So... I ended up taking the average per frame over all ticks, which seems to work pretty well.
Edit: Just found out the FDS modulation can go up to like 1700Hz or so... this thing could do FM! Interesting... I should probably implement that capability.
Also have been experimenting with PAL support, but the pitch comes out slightly low. Not sure why; I'm using the register values vs. FamiTracker's SoundGenerator note lookup tables (after resetting it to PAL).
It's kind of weird too, if I export a PAL NSF from 0.3.6, it will import at the correct pitch, but a PAL NSF from 0.3.7b imports low like the game NSFs I've tried. The issue might also be with NotSo Fatso (or even with NSFPlug; how do I know which one is correct?).
Another random thought: did europeans use arpeggio a lot more because they sound nicer at the slightly slower 50hz?
Edit: Hmm, the emulators I've tried seem to agree with the lower pitch I'm getting. Maybe NSFPlug is playing back at the wrong pitch and the results I'm getting are correct.
Random question: Is pattern length detection planned to be a feature somewhere down the road? If not, may I humbly suggest a manual pattern length option in the pre-conversion process?
kinkinkijkin: Err, it's not really that simple. PAL games don't play slower, they play the sound at the rate it's supposed to for that system, which if you do things right should be the same pitch as you expect. There's the 60 vs 50hz vsync thing, but also a different clock rate on the PAL chip (unrelated to vsync). What I suspect is that NSFPlug is playing back PAL NSFs with NTSC clock speed but at PAL vsync rate, resulting in an incorrectly high playback pitch (the tempo is correct though). I think I should do some tests with the FamiTracker NSF exporter too.
And no, I have no plans for pattern length detection.
If I eventually write a plugin system I would probably make a tool for reflowing pattern data over a different length.
Well, when you create PAL NSFs with FamiTracker, they export & play in other players at the proper vsync frequency. Considering that NSFPlug was programmed only with NTSC NSFs in mind, I'm not surprised that PAL NSFs mess things up with the player.
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
Everything plays at the correct vsync frequency (rhythm/tempo is fine), it's the CPU clock frequency (oscillator pitch) that's different in NSFPlug, I think. FamiTracker 0.3.7b also seems to be doing something weird with this, which I've started a thread for.
I don't really want to take a billion requests right now, sorry.
Might I suggest reading the discussion before contributing? Helps avoiding cases like this.
Anyway, as has also already been mentioned, the tool will probably be ready within a month, so you won't need to hold your breath for very long. You would've caught that too if you had merely skimmed through the discussion prior to posting.
When I got to VRC7 I thought it was going to be easy... some of it was. Figuring out that volume values are inverted took waaaay too long. I abuse 3FF for pitch bends (not sure quite how well this works in 900bpm mode), and approximate with Pxx for pitch bends after note release.
Edit: this version's a little better; was using note release instead of halt (didn't realize release did something special for FamiTracker's VRC7).
)