MIDI Update

[a740g]

This PR moves MIDI support in QB64-PE out of $UNSTABLE. Additionally, it addresses the issue highlighted here.

Changes:

• The compiled executable will no longer include an embedded soundfont.
• To address the issue discussed in the forum, ymfmidi, Opal, and a tiny FM bank are now used.
• Soundfonts can be loaded using the _MIDISOUNDBANK command.
• Depending on the sound bank type, a suitable MIDI rendering backend is selected.
• The available backends are primesynth (SF2), TinySoundFont (SF3, SFO), and Opal (AD, OPL, OP2, TMB, WOPL).
• For Windows users, a VSTi 2.x based renderer that is configurable by the user is also provided.
• Multiple MIDI file formats are supported: MUS, HMI, HMP, HMQ, KAR, LDS, MDS, MIDS, RCP, R36, G18, G36, RMI, MID, MIDI, XFM, XMI
• The use of $UNSTABLE:MIDI and $MIDISOUNDFONT triggers an appropriate warning message.

New command:

_MIDISOUNDBANK fileName$[, flags$] ' flags$ can be "memory" and one of the supported soundfont/FM bank types

[mkilgore]

Could anything bad happen if someone calls this while audio is playing?

[a740g]

That's a very good question.
primesynth does not support loading banks from memory. So, that's ok.
ymfmidi must parse the bank into its internal structures. So, that should be good too.
TinySoundFont is the only one what uses the sample memory directly from soundfont data during runtime. At least that's what I remember. I'll need to check on this one.

[a740g]

Good news. I checked the code inside tsf.h and it appears that it allocate the necessary memory and then load the structures and sample data.

Just to be sure. I ran a test with 2 different midis using 2 different soundfonts playing at the same time in streaming mode and it worked fine without blowing up.

[mkilgore]

Are decode and stream not mutually exclusive? It's possible to use both, or use neither?

[a740g]

So, we were setting up those that way previously. But it turns out, it's really not required.

Without nodecode the sound will be decoded "on-load" to PCM format else it will be loaded in the original compressed format and decoded "on-mix".
Without steam the entire file is loaded into memory (either decoded as PCM or in the original format based on the nodecode flag). However, with steam only small chunks are either decoded or loaded in the original format.

So, in the end, it boils down to when the decoding happens - on load or during mixing. I ran some tests to confirm the behavior.

I think doing it this way allows the user a lot of control. The only problem is _MEMSOUND. But for that, we do check if "stream" is off and "decode" enabled.