Both 3 and 5 divide into 3600, so there should be no issue at all unless you're using a tempo other than 150. Besides which, you might as well be using F04.
That's not exactly what's happening. Say for instance you have tempo=150 and speed=9. You could just as well have one row at speed=5 and one at speed=4, giving you an extra row for more flexibility while preserving the same tempo originally. Or nine rows at speed=1, that adds up to the same too.
Also there are some tempo values that the NES can't deal with without inserting an extra frame every few beats (this is due to the fact most NES music runs at 60 or 50 frames per second). If you leave the tempo value to 150, you can be sure there will be no irregularities regardless of the speed value. To get different tempos, however, you can insert extra frames manually (alternating Fxx commands). You still get irregularities, but it's easier to tell when they'll happen since you have a visual cue (the Fxx commands).
It's important to realise that whether you do it this way or modify the tempo value directly doesn't change anything. The tracker will still add extra frames every few beats if tempo !=150.
1. How does the NSF determine the correct speed given the tempo value and speed value? Does FamiTracker go through the same calculations as the NSF, or is the NSF slightly off due to float errors?
2. A tempo value of 150 gives the smoothest tempos in 60 Hz, but isn't it more feasible to change the refresh rate in the exported NSF's header to scale 150 BPM to whatever speed desired by the user (even many decimal ones), rather than set the tempo to 2.5 times the engine speed? Does 150 BPM work equally well in other engine speeds?
1. They both use the same algorithm for tempo, so that NSF will be the same as in Famitracker.
2. Changing the engine speed is something that is supported by the NSF specification, but it is not something that NES games could normally do (generally everything is driven by the 60hz video refresh). Many NSF players, and some hardware NSF players do not support custom engine speeds. For this reason, it would not be a good default to have Famitracker automatically adjust the engine speed for you.
Wasn't sure whether to make a new thread or post in here because I'm unsure if it's the same bug or not. At least it's a related issue...
Famitracker doesn't seem to export at the stated BPM when you export a WAV (it might not be playing at the stated BPM either but that's harder to detect).
As a test I exported a minute of crotchets at the default speed of 6 (at 150BPM obviously, I'm well aware of the rounding issues that can be caused by changing that without a bit of maths beforehand).
I then imported them into my DAW with the tempo set to 150BPM and sure enough it's audibly out of sync with the metronome after a minute.
I worked it out and it's actually running at ~150.078BPM. I know that's a very small level of error, but it obviously compounds into a much bigger error eventually. I wouldn't consider that kind of drift a bug in live playback, but during an offline render there shouldn't be any drift unless there's an error in the maths right?
It's not like it's an insurmountable problem to work around but I still felt like I should report it because a bug is a bug. Sorry!
EDIT: Oh yeah, extra info that I forgot! The error seems consistent. That is to say that tracks exported separately stayed perfectly in sync, they were all running at ~150.078BPM. So this seems more like a mathematical error than something like system load delaying things (which makes sense for an offline render).
I believe it's not a math error per se, but a simple side effect of the frame rate not being exactly 60 fps (though much closer to it than the NES true frame rate of ~60.1).
I was thinking about what you said and wondered if perhaps when the engine speed was set to NTSC it might actually be running a little fast deliberately. So I tried manually setting it to 60Hz using the custom engine speed option.
Firstly, default '60Hz' and custom '60Hz' are the same, it seems to be consistently 150.078 BPM which I make to be the engine running at 60.0312Hz.
Interestingly, running the PAL engine at custom '60Hz' gives a BPM of 150.028. I don't know what undesirable effects might come from running the PAL engine at the wrong speed though.
SirPrimalform: It's true that the BPM value is still rounded and not exactly as displayed, the problem discussed here earlier was of a different kind. The tempo calculation is based on what's possible to achieve when exporting to NSF, rather than having it as accurate as possible. The NSF format (and NES) have limited timing resolution so there will always be some rounding differences.
Running PAL at 60Hz is fine, the difference you see is that the playback speed is derived from the PAL clock (1.66 MHz) instead of NTSC clock (1.79 MHz). The next version of famitracker will base this on the actual NSF clock (1 MHz) instead, so then it should be exactly the same in both cases.
