This tool is pretty much super awesome. Especially when it comes to figuring out some of these slightly weirder, chunkier sounding drums that some games use.
That being said, it doesn't seem to like Metal Gear Solid a whole lot. Looks like it imports things for the most part right, but the volumes get messed up on a bunch of tracks. For example, track 16, the noise channel's volume basically fades in and out weirdly.
Other than that, it seems really effective so far!
Was that post really necessary? I haven't seen any sign of disrespect in this thread. At best you only stated the obvious.
Well, I appreciated his post myself. Positive feedback is always welcome and the future of this project depends entirely on my motivation. :P (although those courageous enough could always fork it)
jrlepage wrote:
The program chokes on this GBS! "Unsupported ROM layout", apparently. What does this mean exactly?
It meant my program couldn't figure out whether it was bankswitched or not. The song data itself ended at exactly $7FFF, but luckily changing a >= to > in the code fixed it. :P
Quote:
More issues! This time this GBS is the culprit. I tried importing track 15 specifically; the import process itself works fine, but the file it spits out runs really really slow. Here it is (and here is a sped up version).
Any idea why this happens?
TMNT2's sound driver actually runs at 240 Hz. So it'll now import it "properly" at 3600 BPM.
This is far from an ideal solution though. If only because it's hard to follow things at that speed. What's worse is that my lazy emulation clocks the volume envelopes at the engine speed (which is around 60 Hz most of the time) rather than 64Hz (which is what they're actually supposed to be). So in the case of TMNT2 they're 4x too fast! I guess I'll have to implement... *gasp* cycle accurate emulation one day.
Anyway, I think I fixed all of the bugs reported! Here's the latest version. :P
I've had enough of Chrome. It thinks your program is malicious. (I already know it's not.) Anyway, the update has fixed the issues I addressed. Keep up the good work, Slimeball!
Great work on Prehistorik Man and the "zombie volume". :D I think I understand it now too.
Man this looks like a lot of fun to develop. :D
~~~~~
Edit:
I've noticed a lot the imports stop at pattern $1C and end with a Cxx command when they should obviously be looping. Project S-11 and Prehistorik Man tracks for example.
The importer doesn't loop modules automatically. You tell it when to stop logging to FTM, and then you have to make your modules loop properly (which can be an arduous task sometimes).
Unlike SPC files, there's no field for playtime and loop length in the header. Loop points are encoded into all the music driver's respective formats themselves.
Writing something that recognizes loop points would be really hard. Especially since I imagine a lot of songs use non-integral tempos (such as 127.3 BPM) aliased to 60Hz, resulting in the placement of notes being subtly different on looping.
I think it'd be a lot easier (relatively) to write something that recognizes instruments. :P
GBSImport imports 120 seconds of music by default. That's also where frame $1C is. If it detects more than 5 seconds of silence, it'll trim off the end. (if you don't disable it)
Yeah, I decided to let the imports halt and be quiet at the last row. In early development it left the notes hanging, and eventually I got very tired of hearing that all the time. :P
What's worse is that my lazy emulation clocks the volume envelopes at the engine speed (which is around 60 Hz most of the time) rather than 64Hz (which is what they're actually supposed to be). So in the case of TMNT2 they're 4x too fast! I guess I'll have to implement... *gasp* cycle accurate emulation one day. 
