[fluid-dev] MIDI Proxy idea

[David McNab]

Ken Ellinwood wrote:
> In my opinion, specifying a bank offset when loading the soundfont is
> the best option because a) it avoids the load order probelm, and
> b) its the way the SB Live card works.

Now you've got me confused. The manpage for fluidsynth says nothing 
about being able to specify a 'bank offset' when loading a soundfont. 
The API doco mentions a 'fluid_synth_sfload()' function, which only 
takes the soundfont pathname and the 'update presets' flag.

Or were you referring to future development plans?

Anyway, the idea has occurred to me to write a 'midi proxy' which can 
talk to fluidsynth, and/or an emu10k1 card, or whatever.

The proxy would be preconfigured with a set of bank-msb/bank-lsb/preset 
to bank-(msb|lsb)/preset mappings, and could even listen on a socket and 
accept user commands to change this mapping in real time.

Architecturally, the proxy would:
1) Load up the mappings from a config file
2) Open up a receive port within ALSA
3) According to configuration, either:
3.1) Fire up a fluidsynth with server mode turned on, and open a
     socket connection to it, and send commands to load soundfonts
     in a particular order, and/or
3.2) Connect via ALSA to an emu10k1 card, and spawn 'asfxload'
     commands to clear the memory and load soundfonts with specified
     bank offsets.
Thereafter, upon receiving instrument (or midi file player) MIDI events, 
it would translate these to the commands indicated for the backend.

For instance, if talking to a fluidsynth, it would receive 'note(on|off) 
MIDI events, and translate these into 'noteon/noteoff' command lines. It 
would translate bank-select-msb and bank-select-lsb into fluidsynth 
'select' commands.

Or, if talking to an emu10k1 card, it would map the 
bank-select-msb/bank-select-lsb/prog-change events into 
bank-select-msb/prog-change according to the bank offsets on the card.

The problem is that fluidsynth works from 'bank-select-lsb', while 
emu10k1 works from 'bank-select-msb'. And, possible other 
inconsistencies I haven't yet come across.

The idea is that the proxy would present a backend-transparent 
interface, so that midi files requiring access to instruments from 
several soundfonts could work unchanged, without putting people through 
task of brewing up custom soundfonts for each track.

People would just write a config file which associates soundfonts with 
bank-select-msb values. Thereafter, the midi file would select 
soundfonts via bank-select-msb, and banks within soundfonts via 
bank-select-lsb. Then, people would just add new soundfonts to their 
collection over time, without breaking existing midi files.

Questions?
1) Does this idea suck? If so, please qualify the suckage
2) Would I be wasting my time in writing such a proxy?
3) Would anyone want to use such a proxy?
4) Have I missed anything? Or are there any other features people would 
like to see in a proxy?

--
Cheers
David