i just came across an interesting inconsistency with nsf playback...
So this one intrument that i am using doesnt play right when sliding up ....rather than try to explain...see attached. pay attention to Famitracker versus nsf playback closely...
it seems instrument 1 (with the -1 coming first in hi pitch)and qxx dont get along, BUT only in octave range 4 and up. i did several tests to try to narrow it down to what it was...what octave...whether note slide down was affected (its not)...its really weird, huh?
also stuff like this (with that same troublemaker instrument 1)
C#4 Q42 200
above example sounds fine in FT, but in nsf playback, the note slide gets cut short. i reversed the commands and nsf playback worked fine. this seems to be the case with a lot of commands actually. but again, just in octave 4 and up as far as i could tell.
You could summarize this all by saying that something with instrument 1 (-1 coming first in high pitch) in octaves 4 and up is off in nsf playback. further testing may narrow it down further, but those are my observations thus far. Guess I'll just reverse the -1 and 1 in my instrument for now, as that seems to be fine.
Otherwise the channel available list has the wrong channel index on reinsertion of an added channel into the available list. I know...not a used dialog yet. But I was playing around with it because I wanted to test some CTreeCtrl functionality and noticed this.
FamiTrackerView.cpp/FamiTrackerView.h:
The OnTimer parameter should be UINT_PTR not UINT. UINT/UINT_PTR are equivalent in 32-bit systems but not 64-bit.
ModulePropertiesDlg.cpp(151): The "- 1" on this line is superfluous. It actually generates the wrong track name (off by one...the track names are 1-based). The track name is replaced with the correct name when the list view's selection is updated, which causes an EN_CHANGE event on the song name editbox, which updates the name in the list with the proper (not off by one) number. This helped me find a bug in my EN_CHANGE handling.
EDIT: Because whenever I'd click "Add" in Module Properties [in Qt FamiTracker], the song name would be the same #nn as the last name in the list.
This might be something minor for now, but there seems to be a really weird difference between emulators when it comes to the FDS modulator unit. My carefully tuned sounds are all over the place, and ironically, NSFplay seems to be the worst one at it. As far as I remember jsr, you have a FDS to experiment with. Whether the module sounds the way it's supposed to or not, could be an indicator of where the problem lies. I have no idea if it's the emulation in Famitracker, the NSF builder, or actually the emulation is correct, and the players are inaccurate.
There is nothing wrong with the NSF export, the sound emulation within Famitracker is merely inaccurate. High frequency use of the modulator isn't done in any FDS game, so it is very poorly emulated.
I made a serious effort to get it as accurate as I could with NSFPlay 2.3, and I would claim it is currently the most accurate FDS emulation (though nothing is 100% accurate). The high frequency modulation effect is very complicated and difficult to reverse engineer.
Here is a recording made with my FDS for your comparison:
After looking a bit at what is going on in your example, I will make a recommendation for Famitracker's NSF driver, though: writes to $4085 do not reset the phase of the modulator, but many emulators incorrectly emulate it this way.
The only way to really reset the phase of the modulator is to halt it and write the entire mod table. I would recommend that Famitracker does this on every new note (in addition to the write to $4085) so that the phase will be consistently reset, and it should perform more consistently across emulators.
In your example that I recorded, it is clear that the modulator phase is not being reset, and its phase vs. the waveform phase is variable as a result, which makes for a sort of randomized timbre. Because of the high frequency effect, and because with my setup I am not currently able to test something like this on the hardware with timing that is identical to the NSF, even if NSFPlay's emulation was 100% accurate the modulator phase can easily be very different based on these small timing deviations, unfortunately. Eventually I could try writing some new software to make a better hardware test with perfect timing, but for now we have demonstrated that the NSF produced by Famitracker is not resetting modulator phase, which is the most prominent problem with the NSF driver here. (The frequency difference in Famitracker's modulator emulation is also a problem, but this doesn't affect the quality of the NSF.)
It's...pretty mind blowing how Famitracker allows you to use the modulator with results similar to what you could hear in case of a Yamaha chip, even though the actual hardware gets it all randomized.
Thanks for the recording by the way, at least I had the intention of pulling more out of the system, if not much else.
I forgot to report this before, but for some reason this ftm doesn't seem to save the final dmc as noted in the module comments. I still have 59kb unused and I know I've seen some other ftm with all 64 sample slots used up and it saves&loads just fine.
