Re: [fluid-dev] Soundfont banks

[David Henningsson]

On 07/10/2012 12:56 PM, jimmy wrote:
> Read the points I tried to make in my prevous message as quoted.  Soundfont 
> specs is a bastardized standard, to partially support MIDI.  MIDI supports 
> 128x128 banks, Sounfont specs chose to only allow 128 in their infinite wisdom.

> I brought up the point before and asked what to do with the MIDI spec.  I got 
> no answer from you or Pedro.

In your emails, I sometimes have a hard time separating the facts you 
provide from the opinions you also provide. This might be part of why 
you feel you don't get an answer for some of the stuff you say. Another 
is lack of time on my part.

> When there is a will, there is a way.  To move forward to full MIDI 128x128 soundbanks, 
> FluidSynth can move beyond the 128 soundbank limitation (of SoundFont specs) without 
> breaking the Soundfont specs in anyway.  Just think of a sound font file as 128 sound 
> banks, plain and simple.  Now to support 128x128 soundbanks, just find a way to allow 
> loading and using 128 different soundfonts simultaneously.  Assuming the current 
> situation as the "default" soundfont, index=0.  For GM, MIDI2, XG, the current 
> soundfont should map to MSB (CC0) value 0.
>
> Supporting that idea could be done various ways, one simple way is to say each 
> soundfont file maps to one unique MSB number (for GM/MIDI2/XG mode, use LSB for 
> GS mode), specifiy that in a config file, or some function parameters (for 
> library loading), or commandline options...
>
> Again, this doesn't break Soundfont specs.  It may work differently from 
> current behavior.  Because right now, loading multple soundfonts just override 
> each other in the confined space of one set of 128 soundbanks.  Which is not 
> quite a full-MIDI support.

I don't mind figuring out a system for mapping several soundfont files 
to different MSB's and LSB's, through some kind for soundfont bank 
offset functionality. It is not clear to me how that will work out in 
the different modes, especially not in combination with drum channels, 
drum presets and drum banks.

But before we actually have that system figured out, patches written and 
committed for how to do this, it does not make sense to me to commit an 
XG bank selection patch that just causes the total value (MSB*128 + LSB) 
to go out of range. Especially when we have an mma mode that already 
does just that, and is perfectly possible to use, if you desperately 
want values that point nowhere.

> Also, as MIDI hardware always do, if a specific soundbank is not valid (not 
> implemented, no such instrument-set, no such drum-set), either keep the 
> existing bank/instrument, or revert to the default (selection number=0) 
> bank/instrument.  Which is how my rejected patch try to do in XG-mode with 
> FluidSynth.
>
> For example, in XG-mode with my patch, if the MIDI-file or MIDI events from 
> MIDI cable try to use [MSB, LSB] soundbank of [120, 87], for the time being my 
> patch would map that to [0, 87] for normal channel, or map to [0, 87] for drum 
> channel, until FluidSynth can support loading 128 different soundfonts for full 
> MIDI mapping.  Assuming there is a soundbank at 87, it would be used.  If there 
> is no soundbank 87, it would try soundbank [0, 0] for normal channels, or  
> soundbank [0, 127] for drum channels.
>
> I also think that's how things should work with GM-mode, and MIDI2-mode.  
> Currently FluidSynth can't deal with [MSB, LSB] combination, so it is very 
> broken with respect to full MIDI handling for soundbank, the way I see it.

The General Midi (GM1) spec does not include bank selection messages at 
all. Therefore all bank changes are ignored in GM mode. That method is 
compliant with the General Midi (GM1) spec, but maybe not "how you think 
things should work".

> I pointed this out in my previous posting on the mailing list without a 
> response from you or Pedro.
>
> Moving along, I still think FluidSynth should support loading and using up to 
> 128 separate soundfont files in their separate 128 slots, instead of cramming 
> multiple soundfonts into one slot the way things work right now.
>
> Of course, I'm not saying you or Pedro have to implement that.  I'm trying to 
> say things aren't even MIDI-1 compliant, let alone MIDI-2.

As previously stated, the GM bank selection mode (i e, ignore all bank 
selection messages) is compliant with the GM1 spec. Please stop saying 
that it isn't.

> Acknowledging that, then perhaps there is hope of finding a way to add code to support 
> the missing MIDI feature.  What I'm trying to say is "Soundfont specs" alone is 
> inadequate for full MIDI support.  If you and Pedro only care about Soundfont specs, 
> don't care for MIDI specs, then that's your perrogatives.  I do want MIDI supports.
>
> Implementing that would take some work, but not if patches are ignored.

Patches are more likely to be accepted if we first agree on what should 
be implemented.

> My rejected patch deals with that broken handling of [MSB, LSB] in a limited way in 
> XG-mode, but was rejected because you and Pedro don't care about XG-mode handling. By 
> "limited way", I mean without the drastic code changes to support the full 128 
> separate soundfont files.

As for your other email about what you think is wrong with the current 
patch, let's get back to that when we have the soundfont bank offset 
functionality in place.

// David