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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
