![Image](http://i.imgur.com/PpuNVgp.png)
It's also responsive!
![Image](http://i.imgur.com/x0nLVu5.png)
I'll upload the update as soon as it's finished
Screenshot(s) of the next update!
Moderator: Staff
Oh, it's a doozy. VB kinda pulls a MAME on this program (in fact, many of the chips are from MAME/MESS) and has some glue code for the multimedia interfacing. The VGM processing code itself I'd prefer be cleaned up.vampirefrog wrote:I dunno, to tell you the truth, I haven't looked at vgmplay source yet.
Code: Select all
function YM2151(clockRate, sampleRate) {
this.reset = function() { ... };
// use an Int16Array for buf
// https://developer.mozilla.org/en-US/docs/Web/API/Int16Array
this.update = function(buf, length) { ... }
this.writeReg(reg, value) { ... }
this.setMutemask(mask) { ... }
}
/* You may also wish to add some extra functionality, like a note callback */
var ym2151 = new YM2151(4000000, 44100);
ym2151.onNoteOn = function(note, channel) { ... }
ym2151.onNoteOff = function(note, channel) { ... }
vampirefrog wrote:After taking a look at the chip emulation code, I realize it is not so hard to rewrite the chips in JS. YM2151 and YM2612 seem a couple of the more complex chips.
So, it looks like you're on the good path with the way you've written things so far. If you choose to focus on vgmrips, I suggest you begin with the most used chips (http://vgm.mdscene.net/packs/chips - as you can see they're ordered from most packs to least packs) - NES APU, YM2151, AY8910 and HuC6280. That way you will have big coverage. If we cover the first 6 chips, we'll have over 800 packs covered out of ~1.1K. Not bad. We can then implement your player on the packs page selectively - where the player can emulate all the chips in the pack, use it, and when it can't, we just use the ogg player. As you can see, there are 32 chips, so hopefully I can help with a few, maybe the simpler ones like AY8910.
As far as the chip code goes, I suggest you pick a standard interface and stick to it for all the chips, such as having a couple of standard methods for the chip classes. Just an example:
Also, as a bug report, the player does not work on chrome, and I'm using latest stable chrome. It works on firefox. What I've found is that the chrome web audio api has a bug in which onaudioprocess() does not get called for a ScriptProcessor node. What you can do is force the backend to flash for chrome, and add an option to choose/force the backend in the UI.Code: Select all
function YM2151(clockRate, sampleRate) { this.reset = function() { ... }; // use an Int16Array for buf // https://developer.mozilla.org/en-US/docs/Web/API/Int16Array this.update = function(buf, length) { ... } this.writeReg(reg, value) { ... } this.setMutemask(mask) { ... } } /* You may also wish to add some extra functionality, like a note callback */ var ym2151 = new YM2151(4000000, 44100); ym2151.onNoteOn = function(note, channel) { ... } ym2151.onNoteOff = function(note, channel) { ... }
Also, the sound is very skippy on IE unfortunately
Cheers!
Chrome 34.0.1847.131m has some jittery sound for me, but that's partly due to the window not being focused combined with my crappy connection. I don't currently have Firefox on my dev machine, but I might put it back eventually.vampirefrog wrote:After struggling with the WebAudio API and seeing how crappy support is currently (Firefox kinda works, but Chrome has not worked properly for me, no IE support), and looking at your project, it seems the best back-end is indeed one of sink.js or XAudioJS.
If it works, fantastic!vampirefrog wrote:I'm not sure how good an idea is to port chips to javascript by hand, so using emscripten is a more practical choice for a full VGM player at this point.
Yes, for VGZ processing. I'm building this for SMSPower to use as well (which they technically can if they don't care about YM2413 playback yet) and eventually Project2612, so it needs to be able to load a pre-existing VGM file (compressed or uncompressed) from the same domain (uses AJAX, so subject to cross-origin restrictions by default) and play it all client-side without being dependent on anything special (all the dependencies like jQuery are front-end deps). SMSPower hosts all their soundtracks and in zip format, so that's also a bonus (don't yet know of a client-side 7z parser for the vgm7z packs, though; that would be server-side :/ ).vampirefrog wrote:Also, I've noticed you want to add decompress(). Is that for vgz files? In the particular setup of the packs project, that won't be needed, since we'll be sending the vgm data uncompressed, but the http request itself can be gzipped. We can just do that from php no problems.
Once I finish v1.50 parity (PSG, YM2413, YM2612, YM2151), then I'll focus on vgmrips-popular chips first, yes.vampirefrog wrote:So, it looks like you're on the good path with the way you've written things so far. If you choose to focus on vgmrips, I suggest you begin with the most used chips ... - NES APU, YM2151, AY8910 and HuC6280. That way you will have big coverage. If we cover the first 6 chips, we'll have over 800 packs covered out of ~1.1K.
IE likely uses the Flash fallback that XAudioJS provides. Once I do the cleanup rewrite and increase buffer sizes that might be resolved. Increasing the buffers sizes might resolve the Chrome issue as well, though I'm actually getting playback on mine.vampirefrog wrote:Also, as a bug report, the player does not work on chrome, and I'm using latest stable chrome. It works on firefox. What I've found is that the chrome web audio api has a bug in which onaudioprocess() does not get called for a ScriptProcessor node. What you can do is force the backend to flash for chrome, and add an option to choose/force the backend in the UI.
Also, the sound is very skippy on IE unfortunately
I'm not touching Flash. Anyone else wants to port my code to ActionScript, be my guest, but I'm not going to be the person to do it.vampirefrog wrote:It has also occurred to me that if we write the chip code carefully, it might work in ActionScript as well, so we can have the playing part directly in flash, where we might get better results with the playback, and we can just use the UI in javascript and just send control signals to the flash app. Later, when the WebAudio API stabilizes (or when we're on firefox, where it seems to work fine), we just serve the plain JS. But otherwise, serve the flash app and have a JS interface to it. As we've seen, all the chip emulation web players use flash one way or another.