I wasn't quite expecting the hostility that seems to have shown up in this thread. Interesting response.
I know that there are quite a few more VGM player solutions nowadays than there were back in 2011 when I first started to get serious about a web VGM player in JavaScript and in 2015 when I finally got the YM2612 for it working, and I know that there are at least two other web players, both Emscripten-ed from C or C++ source. What does it hurt having JS versions of VGM chips that don't need to be compiled/transpiled through Emscripten? These chips were ported nearly one-to-one line by line, with very few changes made to accommodate JS as its language and the web as its primary environment, and I've proven that VGM functionality (playback and even non-playback processing) can indeed be done in pure JS in and outside of a web browser without relying on Emscripten or other %LANGUAGE%-to-JS conversion solutions.
I've always treated HTML+CSS+JS development as a rapid prototyping environment. I've already added per-chip volume sliders to the interface (I'm still working on the interface) and I might even get per-channel mute toggles going pretty soon. Considerably less code needs to be added to this project as it is right now to turn it from a player to the JS equivalent of any of the command line tools, and even an updated VGMTool is easier to make using this HTML+CSS+JS combo than my previous stalled attempt at v3, mainly due to stability in making the interface.
I'm no stranger to the requirements of low-powered or small screen environments like laptops, tablets, and smartphones; I'm always working on mobile or laptop for something, so I become acutely aware of when performance becomes an issue. Electron is just a temporary means to an end for this project and I'm not married to it; I could have just as easily uses PhantomJS instead. Also, all work on the cores here also benefits not only my web player but also any potential web projects that would like to make use of VGM audio on a chip-by-chip basis. For example, with some work devs can come up with JS VGM trackers that only cater to reduced sets of chips (a CPS-1 tracker with only YM2151 and OKIM6295, a Genesis/Mega Drive tracker like VGM MM with YM2612/YM3438 and SN76489, a QSound tracker, etc). People can take the scripts and make their own interfaces instead of my Electron-based desktop UI or my jQuery-based web UI. People can integrate individual cores to power the retro audio of their webapps; for example, I myself have taken the YM2612 JS and given it a VST-like wrapper, allowing people to control the synth on a web page with a VST-like API.
The most important result of porting these cores to JS by hand is that not only do they exist, but that they're also as readable, and therefore maintainable, as the original code, if not more so, and don't require external transpiler solutions to generate. I even put off using anything Node.js as long as possible given that the Node community is full of code snobs who insist on using HAML or CoffeeScript or Grunt or the workflow du jour to make something that can easily be written in plain JS, a server side language like Python or PHP whose development isn't driven by hipsters and can be run on pretty much any server setup, etc, and that up until this point every single line of code I wrote for those cores was usable with maybe 4 or 5 lines of boilerplate wrapper in every single JS environment possible, even if the output isn't audio. While I myself did not benchmark any of it against the original VGMPlay, I have in the past asked for others more capable than myself to benchmark it against not only VGMPlay but also MAME's own Emscripten-ed code (what the Internet Archive uses) with no interested responses from anyone with the skill to do so.
I did not expect to have to justify the existence of a VGM player written in JavaScript in 2017. The main advantage of dynamically generating the audio client-side instead of rendering a full audio file server-side and playing that is obvious. While SMS Power user BlackAura may have been the first to write a web VGM player in JS, I took his SN76489-only work and made the first real VGM v1.50-compatible web player in 2015, something that didn't even exist for the decade before it since 1.50 was first finalized. Nobody accomplished that before me, not in Flash and not in Java. I did not expect to have to justify the existence of any VGM player in 2017. Though VGMPlay and in_vgm are currently the reference implementations of VGM playback, maybe people want different interfaces with different levels of control, and the current offerings may not necessarily provide that control.
I never intended for any of my JS VGM work to be the most performant of JS VGM offerings, but at least it's something. I never intended for my JS VGM player to be the de facto desktop VGM player, but at least it's something. Yes, VGM as a format has grown beyond three Sega chips and a Capcom chip, and so too will VGM in JS, and I have a gut feeling we won't be using Emscripten or other semi-automated conversion solutions to make that happen. As it stands right now, all one needs to do is strip the Node.js wrappings from my code and SMS Power can easily have an on-site JS player that only needs and uses SN76489 and YM2413, and Project 2612 can have an on-site JS player that only needs and uses YM2612, SN76489, and Sega PCM. VGMRips can easily use my player for chips that are complete and keep the existing solution as the player for VGMs with incomplete or missing chips while they're written on a chip-by-chip basis (I'm not saying mix players, I'm saying if the code detects a missing chip then use the server-side render for the entire song, else use the client-side solution). Will this be the official solution, only time will tell.
I can see why that Yarm guy decided to take his VGM2OPM project down a few months ago, but unlike him I actually have real investment in this, emotionally and physically. I want to see VGMRips succeed, thriving and expanding. As the largest curated host of sequenced video game audio, VGMRips has achieved success in this regard. I want to see the VGM format succeed, thriving and expanding. As the de facto file format for dozens of different retro video game audio chips, VGM has achieved success in this regard. As a community that promotes furthering either, however, both have failed. VGM as a format stagnated at 1.50 for years, being limited to SMS Power and Project 2612, and it took ValleyBell and eventually myself to revitalize public interest in the format once (Dega) Dave, Maxim, and Bock went hands off. Only then did Oerg866, Tom/nineko, and eventually vampirefrog come along to get VGMRips going and actually provide a location where VGM expansion could flourish, but even now people still go to YouTube or KHInsider or FFShrine to listen to retro video game music.
I put in a lot of work to understand the SN76489 and the YM2612 since 2005; granted I was mostly reading other people's research, but I had also made real attempts to apply that research usefully. I put in a lot of work since then to not only read the code that makes up VGMPlay/libvgm, most of it borrowed from MAME, but also to understand it at least enough to port it to any other language, let alone JavaScript, by hand. The fact that I can do so at all means it's possible, whether I optimize MAME's style or not. If somebody wants it to be performant, great! Feel free to volunteer to help me in that endeavor; it's on GitHub, so it's as simple as making a pull request, or one can even email me code and I'll try to integrate it properly myself. But don't anyone here fucking dare try to discourage me or anyone else from attempting to develop something useful to the VGM format or the community, native or not, performant or not, VGMPlay-based or not. I can't believe that has to be explicitly said or written here for any reason.
|