VGMPlay-js new version

By niek

Expert (112)

niek's picture

04-01-2020, 00:35

I've been working on a new version of the Javascript version from VGMPlay. I'm focussing on very easy integration in a site. Right now I've gotten in to the point the only thing required is one script line at then end of the HTML file. When doing that the class will be initiated and will behave pretty aggressive. It will scan for 'a' HTML tags and then check the href for the word .zip. If those are available the zip files will be extracted in a Javascript Emscripten in-memory file system. This expects a vgmrips.net compatible .zip file. If actual vgm/vgz files are in the filesystem the HTML from the page will be modified to include a player with a list of the tracks with the logo from the zip file. Then one can play the tracks. So basically this can be added to any page that offers vgm downloads and right away the tracks can be listened. It will cause some data traffic, since the actual playing happens locally the player and music data need to be downloaded. The player will be cached however.

Everything above works fine but needs polishing. But before I do that I would like to know if it's an option to include the player in the vgm download section on msx.org. Then I'll focus on making it look nice, if not I'll take my own approach for my own site. Of course I'm open for suggestions, like where to show the player. One option would be to put a div over the MSX Music player on the right. I could also put it between the link and the remark section.

Login or register to post comments

By ren

Paragon (1934)

ren's picture

04-01-2020, 14:26

That's one hard to read paragraph.. Wink

Interesting! I recently picked up working on my web hobby project again, and actually embedded Wothke's webVGM last week (wrapped my own class around it, it's kinda hacky, but it works Smile). Haven't implemented zip extraction, but can do that using a backend PHP script (unburdens the front-end (CPU usage & library size), extracted zips can be cached server side). JS parses the m3u file.

It does sound a bit complicated. The sweetest thing would be to have a nice API, so that someone implementing it has the freedom to do that in a way he/she sees fit. Not a big fan of automagic, but it could be a feature of course. Or you can develop a nice API and (separately) your own implementation of it of course (to be embedded @ MRC) Smile

I suppose you're aware of Wothke's work? It's cool, but also kinda messy & archaic in set up (not modular & all those global vars...), not really made for (easy/unobtrusive) embedding in your own site (that's where you step in I guess? Smile)


(-edit: So.. I kinda forgot /didn't realize you had your own JS implementation already.. (Will have a look Smile))

By niek

Expert (112)

niek's picture

04-01-2020, 18:56

An API is another thing I'm aiming for. Have a look at the github page. It will support some variables (the github page does not mention this yet), if those are set before including the script other stuff will happen. It's pretty simple, just include the 1 line in the html file offering the download and that's it. So no need to implement any server unzipping and stuff, unless you want to offer separate vgm files, unzipped by the server.

Using the api will also be pretty simple; feed it a vgm/vgz file using loadVGMFromURL, use togglePlayback(), stop(), etc. Or feed it a zip with loadZIPWithVGMFromURL. Then there will be an array fileList, containing filepath variables. m3uFile and pngFile will be available as well. Play a file with playFileFromFS. When my own player supports everything I want it to support, I guess the API is just a matter of documenting everything.

I want to do the webpack thing as well, I don't know a lot about that, but I think it should be easy to then host the file somewhere else. The bundle would include the player itself, yrw801 for OPL4, the glue and the css.

By niek

Expert (112)

niek's picture

04-01-2020, 21:58

Ok, now some variables are supported. I will document them later, but look at the vgmplay-js-glue.js constructor.

By ren

Paragon (1934)

ren's picture

05-01-2020, 15:44

You could publish to npm, then we only would have to npm install & import it in our code Smile

You should try to avoid using any globals (vgmplaySettings), better to pass options to the class constructor, or a init method (and thus, move the class instantiation out of the glue file itself (which I just would call vgmplay-js Smile))
I mean, it's not much trouble to load a library, and that add a little JS of your own to instantiate it, much better IMO.

And I would still really separate the core library from the implementation: lib will be smaller & no need for the useAsLibrary check etc. You could have 2 repos for that, but that's prolly overkill in this case, I think it would suffice to put your implementation (as shown in the screenshot) in an 'example' folder.

There are things like displayZipFileList, which are implementation as well.

So how I ideally would see it: a core libary that can take care of loading, parsing & playback functionality, and has the necessary methods (API calls) to do so & an example (or default) implementation which does stuff like the interface/controls, the zip list, showing the screenshot the way you want it etc. Smile

Not a fan of the .zip file scanning, e.g. what if there's a link to a .zip on the page that's not a VGM pack? Smile I would limit what's processed by allowing for the passing of a CSS selector string .e.g "#vmgZipConainer a", or "a.vgmpack" (document.querySelectorAll())

Regarding those setTimeOuts: have a look at document.readyState / the readystatechange event.

Plans on adding a volume control as well btw? Smile

& a 'dist' folder would be nifty Smile

By niek

Expert (112)

niek's picture

05-01-2020, 20:47

Thanks for the tips, I however find some of them conflicting with my main goal of as easy as possible implementation for people that are not interested in the tech behind it and just want a player in their website, similar to youtube integration or Google Analytics. It's actually pretty similar to vgmplay itself, when you compile it you get a full player implementation with it by default. So with audio handling on many OSes, which translates to webaudio, which is also in my thing. And displaying stuff like titles and progress in a track. Compared to that I don't do a lot different, just the unzipping and a little additional GUI stuff like listing all tracks and the logo etc. Being a library is a feature. But you're free to fork the code if you want it to be a real library. Smile The nice thing is that there are no modifications required to vgmplay in my version, if I recall correctly Wothke's player needs those.

I'm thinking about not displaying the Zip file list by default, this way the player can be pretty small on the screen. I'm also thinking about not loading the zip file by default, but including a button when a zip file is detected to load it. If people want it I could use some option to make it selectable which ones will be loaded. Obviously the design requirements will be different for everyone so I'm thinking about how to achieve this. Maybe a floating div option...

I agree on the npm thing, will do I guess. Never created one though, don't know if it'll accept webpack stuff?

I've been thinking about the constructor as well, but the way I do it now I don't need any constructor in my HTML. I don't mind about a few globals since in JS most variables are, I use ES2015 classes to have all my stuff separated in a nice way.

If you offer zip files on a page that are not vgmrips zip files then you should not include the player code. Smile

Thanks for the document.readyState tip.

No volume control, I guess every user has some keys on the keyboard for global volume control, who would use another slide bar? I could want one per chip, but I think the defaults from vgmplay are ok.

By sdsnatcher73

Prophet (3960)

sdsnatcher73's picture

06-01-2020, 05:14

niek wrote:

No volume control, I guess every user has some keys on the keyboard for global volume control, who would use another slide bar? I could want one per chip, but I think the defaults from vgmplay are ok.

I would really like volume control per chip (maybe some would even be interested per channel) and an easy enable/disable per chip (or call it mute). You can hide these controls initially and reveal them on a button click. I would love to be able to listen to SCC+PSG or FM+PSG and turn one of the chips off to see how they interact, what parts are played on what chip, etc.

By ren

Paragon (1934)

ren's picture

06-01-2020, 08:26

Yeah, just to reply on that part for now: that's something I'm missing actually from most implementations Smile

The 'exotic' MDPlayer has it though (and a slew of other cool features, must be the most complete player, rather resource hungry though..)

I find the PSG a bit on the quiet side in VGMPlay (or the SCC is too loud, dunno Smile), so it would at least be cool to be able to boost the PSG a little for the SCC packs Smile

Being able to toggle channels, or even controlling the volume per channel would be a nice toy as well Smile

By niek

Expert (112)

niek's picture

06-01-2020, 21:13

Ok, I'll keep that stuff in mind. CPU usage should be ok with webaudio and javascript. The V8 engine and the one from Firefox are pretty optimized. I remember the progressbar took the most CPU on my old 2009 Core i5 Imac. My current implementation doesn't have that yet, according to the Chrome task manager it's 1.4% of a core for the audio and about 2.5% for the audio decoding... works fine on Android too. No issues in that area as of yet. Smile

One of my old experiments based on kss-js has it per chip.
And what about this one? With tone detection and a per channel spectrum analyzer. :D

By niek

Expert (112)

niek's picture

01-02-2020, 23:14

Making some progress... :)