vgmrips

I have the same version of chrome, and I didn't manage to get it to work, even with all the extensions disabled. Oh well.

Yes, I'm looking at some ActionScript tutorials, unfortunately, it seems like the way to go, unless you can fix the stuttering problem on IE.

I've tested it again on IE and it just says it cannot initialize the audio server, and the same message box pops up again and again, you have to kill IE from the task manager. I'd just try to initialize it once and set a failed variable.

Thanks for letting me know about that; I hotfixed the "cannot initialize" alert into a one-time deal using that suggestion.

I'll have to look into it later, since in IE the XAudioServer seems to return success but fails to fill the buffer. That may or may not be related to a possible incomplete loading of the Flash in my case, though. I'll try to get in touch w/grantgalitz about it if it's not my fault, though.

perhaps try the bundled demo in IE and see if that works.

Also, I took a look at flash, it's way over my head right now, and maybe we can find someone who knows flash instead. They would have to implement the sound + chips, or perhaps show us how to add more chips. The main difference between AS and JS that I noticed is that you have to add types to variables. So instead of var a = 1234; you do var a:int = 1234; Which I suppose makes the code compile to a more optimized bytecode. I dunno.

I'll ask around, and maybe this grantgalitz fellow can also help?

Let's take a look at these two projects:

http://sourceforge.net/p/asap/code/ci/master/tree/
https://sites.google.com/site/sioncenter/top
http://www.bit-slap.net/

ASAP by itself turns out to be rather useless to me since Ci is a Java-like language; I'm only going to look at the JavaScript conversion in the links (which also apparently includes a 6502 emulator, so NES might be easy after that too).

OMG that is a brilliant language. The entirety of the vgm playing core should be written in it

Dude! This is brilliant! WE REWRITE THE ENTIRE VGM CORE IN Ć CODE!

Think about it! This way, the result gets spread across all platforms:

C++ for command line, output plugins (winamp and foobar), maybe a small GUI player.
Java for Android
Javascript for WebAudio capable browsers
Actionscript for the other browsers

The only thing that's missing is ObjectiveC so we can run on iOS, but I think a back end can be written for cito.

A full rewrite would be needed for this project, including each chip, and here is how I would organize the code:

* A chip audio rendering library, with support for all the chips, with nicely uniform calls for each chip, such as init(), render_samples() etc.
* A format specific library, with routines for reading VGM files
* Another format specific library, for S98 files, written to prove the point that multiple input formats are possible.
* Platform specific back-ends: the command-line player, the browser player, the flash player etc. These would contain the main() function and equivalents.

Hopefully we can convince ValleyBell to hop aboard this project, and at the end we'll have a smooth running, uniform across all platforms, single codebase, well written VGM player!

Apparently there are java to objective C converters available, so that's taken care of as well!

I'm playing around a bit with CiPad right now and I'm feeling rather limited. First impression is that it seems to only be useful for generating libraries rather than full-blown apps.

I don't really want to learn a brand new language that doesn't even let me write the interface, so for now I'll stick with writing cores directly in JavaScript on my side. I'm going to try my hand at decoupling the FM core from the JS MDX Web Player to see how easy it is to integrate as the YM2151 core of vgm.js.

Feel free at your leisure, though, to rewrite my existing sn76489.js (or the original SMSPlus-GX/GenPlus-GX sn76489.c from which I ported it) and vgm.js in Ci as a programming exercise to see if Ci as the source language for maintenance is actually useful. I did almost a straight port with the SN76489, so there aren't any outright speed optimizations done yet.

In other news, I've just successfully decoupled OPM playback from the JS MDX Web Player and integrated it into the web VGM Player! I've added the "Street Fighter II - The World Warrior" playlist to try it, though it's noticeably uninteresting without the OKIM6295 support.

Eventually the OPM script will be rewritten to have an API more consistent with how I initially set up the SN76489 and screwy YM2612 scripts, but at least now I have a proof-of-work for dropping in someone else's separate, relatively unmodified core into the thing.

Once I finish finals, I'll go back to working on YM2612 so I can move on to YM2413 and finally finish VGM v1.50 parity.

We only want a library, not a full blown app. That's why I want to write two libraries in Ci: The chip cores and the VGM parsing code. The rest will be implemented per-platform. Most of your JS will remain, for example, in the web player. You'll be developing (reusing) your own interface. We only write the reusable code in Ci. Something tells me you've already understood this.

The language itself is not very different from C++ or Java. It's just subtleties, potato potato.

I've spoken to ValleyBell and he says he's alright with rewriting the VGM code. There are currently 32 chips, so if we divide the task by 3, we will each have roughly 11 chips. But I suppose the system will prove itself once we have a couple of working chips. I'm thinking YM2151 and OKIM6258. The hard parts will be converting from C to an object-oriented language and after that, maintaining the code with the updates to the original C file, by its original authors or maintainers (upstream commits, you may call them).

I'll try to get the project started.

So, it looks like Ci is really stripped down and very simplified (only byte and int lol). Which is fine so far, but I just wanted to note that.

Alright, screw Ci, let's give http://haxe.org/ a try.

Well, I noticed your player works on my laptop's chrome, but if I switch tab, the sound begins skipping, and only plays for a few ms every second. That's because chrome is allowing it less priority. I think this calls for WebWorkers. Though I'm not sure how they can be used. Or perhaps detect when tab is inactive and use a 1s buffer?