Overall it seems that FDS is messed up whenever converting to .nsf. Wave forms will occasionally clip and some times they won't initiate correctly at all. The defects also seem to very depending on what effects that are being used. If no effects are used it seems to be completely broken.
For example if effect 4xy is used then the vibrato will be choppy. But, only if the effect is standing alone in that frame or if there is more then 2 effects through the entire song. If you only have two 4xy through out the entire song only and the effects are limited to only one frame it seems to play normal
Found another minor thing with FDS. I'm using the latest version of FamiTracker from subversion, so the NSF export seems fine, but I've noticed a small difference between the NSF and FamiTracker.
I created an instrument that has an uneven mod table, so it continually wraps around (I was trying to test the wrapping behaviour). I keep playing it at the same note pitch, so the mod bias never resets (via $4085) and it continues on wrapping without interruption.
However, in the exported NSF, it seems that the mod bias is being reset every time it hits the first note in a new pattern (doesn't seem to reset on the second note in the pattern though). It seems like whatever check is preventing the reset in FamiTracker isn't happening the same way in the NSF driver.
The test is attached.
(Also, don't use NSFPlug to listen to FDS mod stuff; it's not currently accurate. I will fix it in my next release though.)
By the way, Roykeru, I think your FDS export bugs have been fixed since this beta build; with the latest version they all seem to export fine to me.
The following from Google Translate: Simplified Chinese to English
MIDI import feature is very convenient, can be reduced at least half of the workload.
However, MIDI import feature really needs some improvement!
Can only import data of the five channels, but only a new project after import ...
I consider that the number of channels that can be imported should be within the scope of the program allows, instead of five ...
I want to say is this: Since this function is part of the process, it is necessary to improve it.
_______________________
I come from China, so I have all the speakers need to rely on Google Translate can you.
rainwarrior: I will check that. I'm using my own NSF player for testing which shares the same code as Famitracker.
YamatoRyou: Thanks for your opinion, but I don't think the MIDI importer is actually useful for anything so I don't see the point in improving it. I should probaly mark it as deprecated and remove it at some point instead.
I understand your reasons for not improving and wanting to remove the midi import feature, but it's not that useless. I've used it once to import a very short tune into famitracker. Is it really a hassle to just keep the current midi import in there for the few people that use it.
This is one of the reasons I want to write a text exporter/importer for FamiTracker. It would make it easier to create and maintain all sorts of importers.
So the bug is that the arpeggio in the instrument envelope is triggering even though it's not checked? And somehow that is overriding the channel effect?
Exporter bug: if a VRC6 module contains a line where the sawtooth volume is set to '0' and Vxx to V01, in the exported NSF instead of playing at volume 32, the channel is silenced. It seems to work fine within instrument envelopes however.
EDIT: Another unrelated bug - changing "Show row numbers in hex" and then clicking "Apply" does nothing; you have to click "OK" and close the window for it to take effect.
I don't know if this has been brought up before, but when using a fixed arpeggio instrument the pitch slide effects (1xx and 2xx) don't work and I think Rxx and Qxx don't work either.
Qxx and Rxx work, but the slide is always at maximum speed. 1xx and 2xx do not work. Perhaps because of the nature of fixed arps (in which the last value is implied and changes depending on which note you input), but I'm not sure how it works exactly.
