Hey, cool. Did he just compiled/ported it, or did he have it laying around already?
I asked him and did research about makefiles etc., I've been in contact with the Audio Overload programmer as well to find out stuff. And when things were found out he ported it very quickly, amazing! The good thing is kssplay already had support for playing KSS files from memory, which is required in the way Mike does things. So the porting process was very smooth. The code should appear on Github shortly.
Any reason not to use kssplay for the other files?
Well, the kssplay has a low volume with PSG, that's something that could be improved. As I said a little higher in this forum page:
However if anyone knows how to increase the volume in the C code from the PSG emulator...? emu2149.c it seems at https://github.com/arouge/msxplug/tree/master/msxplug/src/de....
@giangiacomo Though my comment/questions were actually intended for niek (sorry if that was not clear), it's cool reading that.
is OKAXAKI ( @okaxaki on Twitter ) Brezza himself ? Can we ask him ?
OKAXAKI is also on GitHub and He's contributing to github.com/digital-sound-antiques.
Yes, should be the same guy
I just noticed he's active ATM over @GitHub: https://github.com/digital-sound-antiques/in_msx
libkss repo is (visible?) there now as well (or I missed it the first time 'round).
@niek: cool to hear. Regarding MSXPlug/kssplay I also find the PSG too soft in comparison to the SCC (just like with VGMPlay), I got the PSG boosted here by +1.88 dB (atm). Then I also have the OPLL boosted by the same amount, so perhaps it's better to lower the SCC then.. ;) But I guess this stuff is also to a certain extend a subjective matter, cause different MSX models/computers seem to deliver different sound output level balances..
in_msx does read/parse in_msx.ini in which one can define soundchip volume levels. If kssplay parses that (or similar) (it doesn't, right?), we're set regarding this matter? :) (Of course it would also be desirable to be able to adjust @ runtime.)
Anyway, cool there's some stuff going on regarding the matter / kssplay (also from the author himself)!
@giangiacomo: keep us posted, your intentions sound good to me! There still seems to be some things that can be improved upon, like the sub-par playback of some PSG tunes like Vampire Killer's.. (e.g. Wicked Child.)
I guess one can just contribute to https://github.com/digital-sound-antiques ?
I got the PSG boosted here by +1.88 dB (atm). Then I also have the OPLL boosted by the same amount, so perhaps it's better to lower the SCC then..
Can you tell me what you edited?
in_msx does read/parse in_msx.ini in which one can define soundchip volume levels. If kssplay parses that (or similar) (it doesn't, right?), we're set regarding this matter? (Of course it would also be desirable to be able to adjust @ runtime.)
I've downloaded the in_msx source but i can't find any evidence that a file will be read? However, runtime changing would be awesome, and if the c code will support it it'll probably be quite doable to get it to work in Javascript too. Then I can create some volume sliders and then use kssplay for everything.
Ok, new version online.
- With XAK you can now select if you want to hear PSG or FMPAC. (PSG track list not yet complete and there are ways to make the stylesheet bork).
- SD Snatcher is sorted out
And I managed to implement my own volume_setter for the KSS player from GME! I can set the volumes from the SCC and PSG with it from Javascript now . It's a POC ofcourse, my new function set_volumes(double psgVolume, double sccVolume, double opllVolume) I hacked in GME is aimed at KSS and nothing else.
Next is kssplay...
And a next version!
I managed to add runtime device volume control from the webinterface for kssplay. I changed the default volumes already to something better (imho). It's not finished:
- It looks ugly
- It uses a textfield where you can input anything that's max 2 digits, sliders are coming...
- The volume control will only work on games using kssplay.js which are XAKTOG, SD Snatcher, Nemesis 2 and Kingsvalley 2. Of course I'll be switching more...
- Oppl volume control is weird, only half the channels or whatever.
To be continued.
A new version.
- Volume control moved to a seperate div with sliders. Still has some issues, but it's late...
- iPhone support
- Much bigger buffer for the audio frames. Reduces the callbacks by a lot, mobile phones can deal better with that, which will mean at lot less stuttering. Tradeoff is that the buttons respond a little slower.
Hey, I see you made some nice improvements!
Did you convince Mike to implement the chip volume interface or did you hack it in yourself?
Btw: the gain I talked about was just for in_msx, not for a/the JS version or something
+ I noticed for some SCC tunes just keeping it at 0 is sufficient, others do seem to need a boost..
I did had a little go with Emscripten myself a while ago, but found it a bit too much of a hassle (on my Windows machine) + other priorities prevailed
I did have a look at cr-kssplay / the implementation + I had a go with implementing webVGM for my own (little) project
OK, to fancy it up you could show a display of VU meters per sound chip channel (Also shows that you're not just playing MP3...) Where has that scope gone?
Did you convince Mike to implement the chip volume interface or did you hack it in yourself?
I did it myself, I found out Libkss already has support for setting volumes per device, so I only had to make it available in the c interface to get it to Javascript. Although the FMPAC volume thing is weird, some channels are being ignored in the setting, but my guess is that is something in libkss. It's on my list...
The gain I talked about was just for in_msx, not for a/the JS version or something.
Can be, but I agreed completely with your comments. It's a matter of taste of course, on my NMS8250 the PSG was low in volume I remember, but the drums are implemented nicely, I feel one should be able to hear them properly. Hope you like my defaults.
I've been thinking of a per game volume setting, but what should be default? I'm thinking of making the player embeddable. In the URL calling the player one can set the volumes.
I did had a little go with Emscripten myself a while ago, but found it a bit too much of a hassle
It was pretty easy to get it installed in Debian Linux. Compile times of the whole thing are in the second range. Amazing.
I did have a look at cr-kssplay / the implementation + I had a go with implementing webVGM for my own (little) project
Any luck??
OK, to fancy it up you could show a display of VU meters per sound chip channel
It's on my list! However the player provides the audio in 2 channels. So I need some other way to get the data from the separate channels. But I REALLY want that.
Latest version online:
- Support for silence detection, it'll skip to next track when the m3u file is not available/correct.
- Crossfading to the next song when the player is not the active tab using webworkers. Also works on android when the display turns off and the phone locks. Now it works fine in my car. Crossfade will only happen if the song has no end, i.e. stage music that'll loop. I loop them 3 times. That's also a nice parameter for the embedded player.
Going to work on:
- audio disable when paused for too long/have a stop button/something like that. When on pause the callbacks will continue all the time, this causes battery drain on a Android phone. And enabled web audio prevents my iMac going to sleep
- randomiser; play a bunch of songs from random games. Also nice for in the car.
- The player had no support for changing the KSS file without reloading the whole thing. I discovered that with some changes it can. So I can stop using an iframe everytime and preload the player and stuff like that. Performance will be better then.