A plugin can be used in tandem with a directory within which read/write permissions are enabled, a batch script (assuming target is Windows), and
FMOD, an audio library, some map triggers, and an auxiliary program (or not).
You will also need a coder.
Look for "FMOD Studio Programmer’s API and Low Level Programmer API". You need the Windows API (probably don't go for W10's API if compatibility is a concern).
Based on my personal experiments in VFSRST, the system can be created easily.
Based on my experience:
The plugin for the mod must launch the aux program on SCBW startup (or match startup).
The aux program will include calls to the FMOD API and the ability to read and write files in the active directory (IIRC the active directory is considered to be the mod's *.exe file's location).
In the map, designate a few death counters to serve a few purposes relevant to basic music player.
examples:
dc 00 for function "play file"
dc 01 for function "stop playback"
dc 02 for function "pause playback"
dc 03 for function "fade in"
dc 04 for function "fade out"
dc 05 for function "exit"
dc 10 for parameter 1
dc 11 for parameter 2
dc 12 for parameter 3
etc.
and designate some function prototypes.
examples:
function play file: takes dc 10 (INT) to describe file to be played (file to be played must be designated in a 1-to-1 relationship with DC-accessible numbers -- namely, positive integers (I think)).
function stop playback: takes nothing.
function fade in: takes dc 10 (INT) to describe a duration.
etc.
Now.
The plugin (whether by A(s,t)'s GPTP or Neiv or Heinermann or so forth) has direct access of course to the map's DCs. The map itself, in run-time, can set (and read) a bunch of values in the designated DCs. That is obvious. The plugin can also access these values.
This means that for any given map the map and the plugin can cross-communicate.
In the map, any time you want to play music, use your designated functions (that are merely a few specific DCs for which you follow some rules).
Then, the plugin shall read the specific DCs, recognize the special numbers as having meanings, and then output a message to a file or other piece of memory (or message box or stream or pipe or whatever (i don't know all the methods available, i used a file)) accessible to the aux program. (And then it will reset the DCs to an empty value so that it doesn't trip/activate itself again on the next game loop.)
The aux program's sole purpose is to read the message output by the plugin and then use the FMOD API to play/stop/fade music -- that is to say, the aux program does exactly as the plugin commands.
(In the past I used an aux program because I found that an #include directive on the FMOD API in the plugin code itself would cause SCBW to reliably crash to desktop on game startup. So the aux program isn't necessarily necessary given that I don't know for certain if it is impossible to incorporate FMOD API calls in the plugin itself.)
Therefore: the map commands the plugin to perform specific functions by way of DCs. The plugin understands what these DCs mean and delegates the actual music playing to a separate aux program.
---
Anyway, I think this method is the method through which one has utmost control over how the music and what music is played. Unfortunately it is a roundabout method due to my lack of knowledge, but when implemented appropriately, effectively bypasses any of SCBW's music playing limitations (though tbh it is probably perfectly possible to simply manipulate SCBW's own music system).