unzip the project into sphere's "games" folder as is (or unzip it to sphere's root folder and rename it to "startup," replacing the existing "startup" folder)
put any *.vgm file into the project's "sounds" folder (it MUST be vgm; compressed vgz not supported at this time)
run the "game" as normal (see Sphere's instructions on how to run a game)
type the name of the vgm file you'd like to convert and press enter (press tab to auto-complete the name if a file exists w/such name)
if file size is greater than 64 KiB, you will see a "large file" warning; if you press space to continue it will display a message that it's reading the file
wait a while; it can take upwards of 3 or 4 minutes to convert a file, since it's all running in javascript space (ie, "dynamic compilation" and all that jazz)
if the file successfully converted, you will see a positive message and a *.mid file will appear in the "sounds" folder; if it fails, it will tell you it failed
the "game" will exit either way; run it again if you want to convert another vgm
So far, the YM2612, YM2413, and PSG chips are supported with support for the YM2151 coming shortly. This is mainly for me to organize my thoughts while I come up with a plan of attack for writing this in C++ for my VGMTool update. This will be cross-posted at Spherical Forums, SMSPower, and Project2612.
Last edited by neologix on Tue Jun 28, 2011 1:30 pm, edited 1 time in total.
This pops up after the conversion happens, but the resulting MIDI file does seem to work.
However, the resulting MIDI file is transposed a half step down. For example, the original Sonic theme is in A major, and the output MIDI file is Ab major. You might want to add 1 to the MIDI base note in the conversion function, however you do it.
Otherwise, good work! Will this work on optimized vgm files? (HOPEFULLY SOMEDAY)
i've fixed the pitch bend problem! since i was writing the midi sequencer from scratch, i wrongly divided a pitchwheel value by 256 instead of 128 to get the pitchwheel's msb. anyone & everyone grab the updated version!
next release will (theoretically) have ym2151 conversion. after that, i may or may not try adding DAC & preset handling before resuming work on the c++ version.
Another thing I've noticed is that the PSG noise output is a bit off --- I hooked it up to a white noise generator and the notes all smeared into each other. Then I decreased the duration time of each note by half, but kept the note on's happening at the same time, and that fixed it.
Might your note off calculation for the PSG be a bit off as well?
Boozer wrote:Another thing I've noticed is that the PSG noise output is a bit off --- I hooked it up to a white noise generator and the notes all smeared into each other. Then I decreased the duration time of each note by half, but kept the note on's happening at the same time, and that fixed it.
Might your note off calculation for the PSG be a bit off as well?
possibly. i had/have plans to look further into customization of psg noise, even going so far as to assign a different percussion note to the eight possible combos of noise shift rate+noise type. until that happens, the notes are A#5 (midi #69/A440) using GM patch "gunshot" (which has an odd sound to begin with; this may contribute to the cause of the audio "smear" as well). i'll probably also have to apply the old note off algorithm (the one from gym2mid, currently in use for ym2612 & psg) to noise if all else fails.
Boozer wrote:DAC would be amazing.
yes, it would. the main detriment to me doing decent dac handling in this js version is speed; proper dac handling would theoretically require TWO loop-thrus of the vgm: one to find all the unique dacs, store them for temporary playback, ask the user what they'd want them to become (perc/non-perc, particular note); one more to loop thru the vgm and create the proper note events. the first loop-thru would likely be handled on file open (c++ version), making all analysis happen then. i haven't quite decided on final procedure for it, yet.
theoretically, this "error" is INTENTIONALLY set off whether saving to midi is successful or not. the error's message changes accordingly. this is not an error, but me using sphere's Abort command to end the program.
neologix wrote:theoretically, this "error" is INTENTIONALLY set off whether saving to midi is successful or not. the error's message changes accordingly. this is not an error, but me using sphere's Abort command to end the program.
"Invalid start position in bytearray.slice call 0"
I get this every time I load a genesis VGM, and no midi appears. If you want to know, I logged it with kega fusion, and I'm using the Zipped version of sphere.