External Module Player (XMP)

[RhoSigma]

Almost 4 month ago I suggested this as a possible enhancement for QB64 v1.5 here (https://www.qb64.org/forum/index.php?topic=2446). As there were absolutely no reactions to it, I assume that the number of potential users for this stuff is so low, that it's not worth the efforts to put it into QB64.

However, as proof of concept and for the few people who might be interested in, here comes a little demo to showcase the usage of this player library in form of a DLL.

NOTE: This is outdated, please follow the green link above to the most recent update of this demo program.

EDIT: Outdated codebox removed, see note above...

[Petr]

Works well for me! Perfect work, RhoSigma. Thank you very much for sharing it. I wrote just one - to your source, because so, at is is it plays just first five second music for me:

row 109: LOOP WHILE NOT xErr&

[RhoSigma]

Well, if the _KEYHIT = 0 gives you the immediate player stop, then it seems any key is sticky on your keyboard, continuously giving you random keyhits. Did you try INKEY$ = "" instead? Would it give you the same behavior?, then definitly check Your keyboard, maybe a loose cable?

[Petr]

You are right. Something is wrong on my system. What is 17 Keyhit code?

 

[Petr]

Really perfect work. It play also XM files, not just MOD files! I'm really happy about it!

[SMcNeill]

Ctrl-Q should be 17, I think.

[FellippeHeitor]

Interestingly I was providing support to @MLambert last night regarding weird InForm behavior and just learned that shift returns -16 when released, ctrl returns -17 and alt returns -18.

KEYHIT never returns a positive 16, 17 or 18 in those cases.

Another something to notice is that these low return codes were specific to Lambert's laptop, as I don't get them on my machine. Might be a computer setting we couldn't find or a hardware-specific behavior.

These are not old-time scan codes as the wiki can attest. Curiously these are the same codes that web browsers report to JavaScript when these keys are pressed/released.

Also notice that QB64 will keep getting modifier key events from Windows even when the program window is not focused.

[Petr]

KEYHIT always return me the same outputs. Each time the program is started, the sixth value is -17. And indeed, -17 is the code to release Ctrl. This error does not occur in IDE 1.4 64 bit, but always occurs in IDE 1.5 b5e896d (32 bit). The keyboard I use is A4TECH model KD-800L

[RhoSigma]

I work with V1.4 stable, on a HP Pavilion G series Laptop.
I do get the -16,-17,-18 codes too when releasing shift/ctrl/alt keys, but it's not immediatly returned without a keypress/release as for Petr.

However, if we're going to discuss this further, then we should open a new topic, cause this one is about music module playing, not keyboard issues.

[RhoSigma]

Really perfect work. It play also XM files, not just MOD files! I'm really happy about it!

BTW - You find a complete list of supported formats on the official XMP page here http://xmp.sourceforge.net/, the formats are collected in sub-lists for each platform.

And here you find 1000s (really) of different music modules usually packed in *.lzh or *.lha archives, which can be unpacked with 7-zip: http://aminet.net/tree?path=mods

[Dav]

NIce, RhoSigma! Looks like it supports a lot of formats.  I'm gonna look for my old trackers files!

- Dav

[RhoSigma]

Today I did work to make the player operating in near realtime. The version from my inital post does buffer 5 seconds of sound, which would give every intervention like fast forwarding or rewinding a delay of 5 seconds. Also in realtime it would be possible to add some cool effects stuff. I've added oscillators for both, left and right channels in this new version to showcase.

To get into realtime, the tracker modul must be played frame by frame, and most trackers used a frame rate of 50fps (the vertical blank frequency in PAL-TV standard) which was a stable metronom timing base back in those days. However, such a frame is only worth 0.02 seconds of sound data and _SNDRAW needs to be fed quiet well to keep playing stable.

So the following player version works on my hardware, but I'd be interested in results from other people. If you get random disruptions in sound then first try to raise the _LIMIT value in the main loop. If it doesn't help, then add frames to the sound buffer size in line 82 (ie. raise the 0.02 value to 0.04, 0.06, 0.08 etc.) until it works.

NOTE: This is outdated, please follow the green link above to the most recent update of this demo program.

EDIT: Outdated codebox removed, see note above...

[Dav]

Plays very well for me. Using code as is, I'm not getting random disruptions.  Testing on an older Thinkpad R61, Win7 32bit.  Runs smooth.

- Dav

[Petr]

Play good on my system. Is there any way, how find total track time in begin?

I've made some attempts with this (especially here I tried to have the library convert the contents of the MOD file into my memory at once) but it seems that the library releases the content gradually, as it should be played, ie a track 3 minutes long memory writes in three minutes. Or is there a way save an entire song at once to memory?

[RhoSigma]

@Dav,@Petr
Thanks for your feedback, good to hear the realtime concept works as expected.

Petr, in this  version I've added retrieval of information using the xmp_frame_info() function. The current replay time as well as the total time are retrieved via the new UDT which is filled by the mentioned function. (see the PrintTime: routine at the end of program)

To convert more data or the entire song it's enough to raise the buffer size (line 111), just replace the 0.02 with eg. 180 so get 3 mins into memory, even if the song is shorter it will not hurt, the remaining time is then simply filled with silence. But note that if you do so with this version, then the oscillators and timers don't update in realtime anymore, but in the time you've set.

NOTE: This is outdated, please follow the green link above to the most recent update of this demo program.

EDIT: Outdated codebox removed, see note above...