Skip to content

General JavaScript VGM player discussion

Technical discussion about the VGM format, and all the software you need to handle VGM files.

Moderator: Staff

  • User avatar
  • grauw Offline
  • Posts: 150
  • Joined: 2015-02-22, 3:40:22

Post by grauw »

Nice work neologix. Looking forward to future development and getting something I can run on my Mac.

And about hate towards JavaScript, man you don’t want to know the crap I got from some people over coding my assembler in Java. Somehow some people get their panties in a bunch by just hearing the name, and for those people usually C++ is the be-all-end-all. In the meanwhile, it’s one of the few advanced cross-platform assemblers for Z80, and quick as lightning. Just gotta ignore that. JavaScript is a fine language, I’ve used it myself both professionally and privately for many years, and it’s plenty quick in the runtimes nowadays.

Post by vampirefrog »

snip
  • User avatar
  • niekniek Offline
  • Posts: 71
  • Joined: 2017-07-17, 23:28:35

Post by niekniek »

vampirefrog wrote:
ctr wrote:Doubt you'd be able to make a VGM player with emscripten/asmjs that will work well on mobile devices. Maybe webassembly now that it's been "approved".
Oh ye of little faith.
Indeed, have a little faith, I just completed my POC of porting VGMPlay to Emscripten. It's not even alpha quality, but my tests with SCC, FMPAC+PSG, Y8950 and YMZ280B work fine, on my iMac in Chrome but also on my Snapdragon 625 based Android Phone. SCC uses the most CPU power btw.

I don't know what's going on with the CPU at https://www.wothke.ch/webvgm/, but it's true what I expected/hoped, it's a bug. :D :D

On my phone it's a little bit too quick, probably because that works on 48KHz and I hardcoded 44.1KHz in.

http://msxmusic.royalwebhosting.net/vgmplay-js/ for an example. The sound is sometimes too loud, needs fixing too.

I will now redo the whole thing, but a lot less ugly... my goal is to create a lib-vgmplay-js, which uses the original vgmplay tree, and offers a nice interface for integration in websites.

Post by vampirefrog »

niekniek wrote:
vampirefrog wrote:
ctr wrote:Doubt you'd be able to make a VGM player with emscripten/asmjs that will work well on mobile devices. Maybe webassembly now that it's been "approved".
Oh ye of little faith.
Indeed, have a little faith, I just completed my POC of porting VGMPlay to Emscripten. It's not even alpha quality, but my tests with SCC, FMPAC+PSG, Y8950 and YMZ280B work fine, on my iMac in Chrome but also on my Snapdragon 625 based Android Phone. SCC uses the most CPU power btw.

I don't know what's going on with the CPU at https://www.wothke.ch/webvgm/, but it's true what I expected/hoped, it's a bug. :D :D

On my phone it's a little bit too quick, probably because that works on 48KHz and I hardcoded 44.1KHz in.

http://msxmusic.royalwebhosting.net/vgmplay-js/ for an example. The sound is sometimes too loud, needs fixing too.

I will now redo the whole thing, but a lot less ugly... my goal is to create a lib-vgmplay-js, which uses the original vgmplay tree, and offers a nice interface for integration in websites.
Nice job, looking good!

I think the animations on wothke's page also slow things down, make it hard to measure just the VGM playback CPU usage. Perhaps the Project2612 player would be a more accurate benchmark, though it's limited to a few chippos.

Could you setup some benchmarks? For example, choose N random VGM files, each with a different set of sound chips, and render 10 loops of each, and measure how long it took? And then compare different optimizations and see how it goes.

As far as sampling rates go, could you do two benchmarks: 1. rendering at 44100 internally and resampling the result to the sound card rate or 2. rendering directly at sound card rate. I suspect the first will take up less CPU, and I imagine this as a user setting: render at 44100 or render at native rate.

I don't know how you've built your code, but I think you can do away with a lot of vgmplay code, such as the ini file parsing and just hardcode some values or have them passed to the init function as a JS object.

Post by vampirefrog »

seems to work fine on Chrome on Android 5, LG Leon
  • User avatar
  • niekniek Offline
  • Posts: 71
  • Joined: 2017-07-17, 23:28:35

Post by niekniek »

vampirefrog wrote: I think the animations on wothke's page also slow things down, make it hard to measure just the VGM playback CPU usage.
Today I noticed a Windows machine takes only 40% while using the site and it was a slow machine...
vampirefrog wrote: Could you setup some benchmarks? For example, choose N random VGM files, each with a different set of sound chips, and render 10 loops of each, and measure how long it took? And then compare different optimizations and see how it goes.

As far as sampling rates go, could you do two benchmarks: 1. rendering at 44100 internally and resampling the result to the sound card rate or 2. rendering directly at sound card rate. I suspect the first will take up less CPU, and I imagine this as a user setting: render at 44100 or render at native rate.
Sure, however I first need to rebuild my code. Currently it's coupled directly width audio output. I want to generate seconds independent of playback. So the entire track will be generated and kept as wave data in local memory, so then you can drag and drop in the track easiliy. My own Android player ViGaMuP works the same way, as is MSXPlay.js. If I've done this I can run such benchmarks easily.
vampirefrog wrote:I don't know how you've built your code, but I think you can do away with a lot of vgmplay code, such as the ini file parsing and just hardcode some values or have them passed to the init function as a JS object.
I could, but I would like to use the default VGMPlay tree and then exclude files via the make process. Then you can just pull the latest version of VGMPlay and build the Javascript stuff.
Last edited by niekniek on 2017-11-23, 18:36:10, edited 1 time in total.
  • User avatar
  • niekniek Offline
  • Posts: 71
  • Joined: 2017-07-17, 23:28:35

Post by niekniek »

vampirefrog wrote:seems to work fine on Chrome on Android 5, LG Leon
Nice! I had trouble on Windows however, Chrome was way too quick, and Firefox and Edge played nothing...

Post by vampirefrog »

niekniek wrote: Sure, however I first need to rebuild my code. Currently it's coupled directly width audio output. I want to generate seconds independent of playback. So the entire track will be generated and kept as wave data in local memory, so then you can drag and drop in the track easiliy. My own Android player ViGaMuP works the same way, as is MSXPlay.js. If I've done this I can run such benchmarks easily.
The VGMPlay code has seeking built in. You just need to render a buffer every time the browser requests it. You don't need to store the whole wave. You could pre-render the next N buffers if you think that's necessary.

Btw, you can also run the vgm code in a WebWorker, that would run in an actual OS thread, similar to the vgmplay command-line player.
niekniek wrote: I could, but I would like to use the default VGMPlay tree and then exclude files via the make process. Then you can just pull the latest version of VGMPlay and build the Javascript stuff.
That's what I meant. You can also submit a patch or pull request with your build system and any extra macros you define, it would be nice to have it official, I am sure ValleyBell will agree, once you get it working well.

Post by vampirefrog »

Yeah wothke's stuff doesn't work on firefox either. I am sure it could work, although even their scriptprocessor demo doesn't work for me.

I don't know about you, but I'm down for some video game music nostalg.

Image

Post by vampirefrog »

I managed to get sound on firefox, it was because I've uninstalled pulseaudio. Youtube wasn't working either. Now there's sound and wothke's page works, but your code doesn't. (btw I used this).
  • User avatar
  • niekniek Offline
  • Posts: 71
  • Joined: 2017-07-17, 23:28:35

Post by niekniek »

Should work on Firefox now, samplerate will be set as well.

Post by vampirefrog »

It works now. It eats 10% CPU when it has just loaded, then the first song eats 18%. If I stop the first song, it keeps eating 18%. Second song does the same thing, but you can also hear the release of the notes after you press Stop, and then it goes over 100% CPU, so it looks like it's not stopping, but doing something else that stops the music but keeps processing. I think the Stop button should stop all processing, and perhaps you can add a 'fade out' button, and detect when the fadeout has ended and then stop processing.

Also, if you don't mind a feature request: a seek bar with markers for loop start, loop reset, and an input to select the number of loops to play before fadeout. Here is an example:

Image
  • User avatar
  • niekniek Offline
  • Posts: 71
  • Joined: 2017-07-17, 23:28:35

Post by niekniek »

Thanks for testing. The issue is with the way the webaudio is working now; I just initialise the stuff and never kill it properly. With Chrome on OSX it won't cause 100% cpu load, but the tab will keep eating 20% forever...

I will try to implement the web audio part of things in a nice way, including the seekbar, however I will make it also possible to use it without that, so people can implement it their own way.

I might do the webpack thing, so the whole thing can be included using one line...

Post by vampirefrog »

niekniek wrote:Thanks for testing. The issue is with the way the webaudio is working now; I just initialise the stuff and never kill it properly. With Chrome on OSX it won't cause 100% cpu load, but the tab will keep eating 20% forever...

I will try to implement the web audio part of things in a nice way, including the seekbar, however I will make it also possible to use it without that, so people can implement it their own way.

I might do the webpack thing, so the whole thing can be included using one line...
Please don't get over-enthused about the grandeur of your project. You have my full support if you develop a player for the vgmrips.net packs pages. Anything more than that, you're on your own.

Javascript coders tend to include new technologies in their code just because they can, overlooking the fact that they now are using external code over which they don't have control, and which will either bite them in the ass, or someone else who is trying to use the code.

There are two types of JS libraries: those that you can do without and those that are utter bullshit. As you can tell, the former are an improvement over the latter. The way you can tell the difference is if a library has been around for years or decades, such as jQuery. Even their front page hasn't changed for years. They know why people use it, cause it's useful and non-intrusive. They don't give a shit about how stylish their front page is, though I suppose it looks alright. But you can also do without it and use pure DOM. On the other hand, you have stuff like webpack and the deluge of other libraries and tools that, it seems to me, are written purely to get attention to the authors' skills. They seem to be nihilistic attention-seekers who try to reinvent the wheel to feel good about themselves, and to have some sort of "internet presence" to give them status in their circlejerk world of barely-passable coders and gullible managers or clients who enjoy being fed buzzword horse shit. There's nothing wrong with that in itself, but there is now too much noise as far as reusable JS code goes. Reinventing the wheel is fine, but publishing hundreds upon thousands of libraries is not, IMO. It just adds on top of the noise when you're searching for actual usable code. As a coder, the result is pure frustration at how shitty the search results are. They promise more than they deliver, man. JS is too easy. And that means it's too easy to fuck up. Software in general is hard to get right, and the magic ingredient seems to be time. If your software survives for more than a few years, and that's why I chose jQuery as an example, it means it's doing something right. So as a user of these libraries and tools, you'd want to look at how old the project is. Grunt and Webpack are 5 years old. jQuery is 11 years old. I think another clue is looking at the front page of a JS library, if it's too flashy and uses too much padding, it's a clear sign that they're overcompensating with graphical design what they couldn't do in code. What a shitload of fuck.

It's hard to take these people seriously.

Who needs grunt when you have GNU Make, a package that has worked and has been stable, documented and tested for over 40 years?

You could make the argument that older software will no longer be maintained at some point and that might be true, but the newer stuff has yet to prove itself and give the reliability that the older stuff has.

And that's not the end of it. It pains me to see well-meaning people falling for it and using immature libraries and tools, for the sole reason that they can. Mark my words, you will pay with time and stress, and nothing can buy your time back. The better alternative is to rely on stable platforms. JS itself is fairly stable. Chrome and Firefox are stable. Some shitty JS library written a couple of years ago by some guy isn't stable. You can bet on that. Linux is stable, even Windows is stable. C is stable. PHP and Apache are stable and have a long tradition. In fact, Apache, PHP and MySQL have the same age, 22 years. You can make your own list of strictly reliable software and then another list of "I'm not 100% sure but it's worked fine so far", and then a blacklist and a list of signs that point to wanker software. Wankware.

Sorry about the rant, I'm just venting about the state of JS coding, it wasn't aimed at you.

It looks like webpack would be useful if we'd use node.js as well, but on a server environment you can just use the C version of vgmplay. Either way I'd focus on getting it to work well, and if you really want to make it reusable, do that after it works well for vgmrips.net/packs. That will be your selling point.

Edit: you could argue that WebAudio isn't stable itself, and that's true, that's why I said a while ago that we need a maintainer for this stuff, to keep up with the changes in WebAudio. Someone has to keep an eye on it and test it constantly, in order to compensate for its state of flux.
  • User avatar
  • niekniek Offline
  • Posts: 71
  • Joined: 2017-07-17, 23:28:35

Post by niekniek »

I agree with your text for a big part, I don't like Grunt, and in my website experiments I even tried to avoid Jquery because I don't like bloat either. I failed on that, but still... I also like to try new things though.

Off topic: you might have a look at Jhipster, I'd say you hate that as well. :) It generates 250MB of data or something like that before you even wrote a single line of code. :)

I also like to keep logic and presentation separate from each other. Currently, my experiment combines accessing the C code, is meddling around with WebAudio Stuff and is the presentation at the same time; so it's a mess.

So I think I want to create a library for accessing the VGMPlay stuff, which then includes an optional WebAudio 'driver' so users don't have to worry about all that, and then I'd have to decide how I want to include the graphical stuff. For the last one Webpack might be nice: 'Webpack is a build tool that puts all of your assets, including Javascript, images, fonts, and CSS, in a dependency graph.' So just one include, you get everything. So then I could offer to use it as a library separately by just including a javascript thing and then offer the whole thing through webpack. Might be a bit too much if a slider is everything being graphical though. And I might think of a nice way to separate the slider logic from the presentation... since you want to decide the looks from your own slider... not sure yet... I want you to be able to really use it as a library.

WebAudio is pretty weird I must say... the current scriptprocessornode is deprecated but there's nothing new, even the new spec (based on the never implemented older new spec) is not accepted as a standard yet! But hey, it will work for the coming years...

Anyway... current state:
- Webaudio CPU usage should be quite normal now. The YMZ280B emulation (first track) is using ~10% cpu now overhere! :)
- I can now insert a URL. URL has to be on the same server though: try http://msxmusic.royalwebhosting.net/vgmplay-js/03.vgm
- Slider works kind of. It's not finished and the dragging doesn't work well on the first track, it works kind of ok on the 2 others
Post Reply