Umm, I'm going to revise the "Valid NSF Files" section, since they still will import as much as they can.
Yeah, I did mention that the importer would import as much as possible, though I agree the valid/invalid wording could be improved... "Limitations" sounds good.
Perhaps the list of limitations could be copied over from the TXT file?
Anyhow, that's fine. You mention bankswitching at the top and then again in the DPCM section; probably only needs to go in the DPCM section. Also as I said, this only applies to mid-song DPCM bankswitching (which as far as I've seen, no original game does) and I would probably clarify this point.
Why are you "miffed?" What alternative do you propose other than an ungodly number of instruments?
All I said was that the limitation slightly annoyed me. Geez.
I'm not sure if I have an alternative. It would be nice to actually convert the data in the NSF into FamiTracker instruments and take a good guess at the song's BPM based on the length of notes (or allow the user to make that guess).
Granted, I know very little about the NSF format other than the header, which I had to learn in order to gain control over what song plays when using the S-WinAmp extension for Game Maker.
--------
And suddenly, BUG.
The NSF importer cannot parse NSF files made with FamiTracker (or at least any of the NSFs I made with FamiTracker 0.3.6). I'm not sure if this is due to quirkiness on FamiTracker's part or quirkiness on the importer's part.
_______________________
SMB: CotN progress: Working on Tech Demo
NSF is basically just an NES rom with a little bit of extra code added to just play songs, and the header to tell you where that code is etc.
While there are coding practices that are pretty similar to what FamiTracker does with instruments, there's no way to automatically figure it out. It takes hours of disassembly/analysis to work out how an NES ROM's music code works.
The NSF importer just dumps the actual sound control data that is output from the ROM's music code. At that point, any knowledge of how the code produced that control data is lost.
So, the best I could do is analyze the imported data. It's easy to look at it and do this by hand (oh, I see this string of volume 8 9 A A 9 9 8 7 6 5 3 1 over and over, that must be an instrument), but coming up with rules to automatically recognize this reliably are next to impossible (they'll work sometimes, and produce unreadable garbage other times). Sometimes there are things done in game music code that just can't translate to FamiTracker instruments at all, because these engines can do whatever the programmer needed (see Blaster Master's triangle channel for an example).
Also, even if it were possible to do it, it's more work than I'd be willing to put into it anyway.
Anyhow, if you need to extract instruments, do it by hand. A number of people on this forum have been making covers with way.
I have problem with this. I've tried to import original Nintendo "black box" Pinball NSF file and got "Couldn't parse NSF" error. NSF file itself is 100% correct though, as I can play it just fine with VirtuaNSF.
Please attach the NSF in question if you want me to look at it. Just because it plays in VirtuaNSF doesn't mean it's a valid NSF file; there is probably something wrong with its header.
I was making my Demo Compo #2 entry when I suddenly decided to put it through NSFImport. Something strange happened. Don't worry, it's only a measure on one channel.
_______________________
Everything moves real slow when it's 40 below.
