[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Soundfont banks

From: jimmy
Subject: Re: [fluid-dev] Soundfont banks
Date: Tue, 10 Jul 2012 03:56:04 -0700 (PDT)

--- On Mon, 7/9/12, David Henningsson <address@hidden> wrote:
> >
> > Sadly, my patch never made it to the SVN code base, so
> the XG-mode soundbank selection and drumbank selection never
> worked in the official FluidSynth code base.
> You do have a bank selection patch merged, see:
> http://sourceforge.net/apps/trac/fluidsynth/changeset/401/
> Did you not see this, are you referring to another patch, or
> was the 
> patch changed (before commit) in a way that broke it,
> or...?

That change was only a partial implementation, I think it might allow for 
setting a channel to drum mode.

My additional patch was never applied, which deals with the MIDI event handling 
and MIDI file usage of the combined [MSB, LSB] mapping -- again only in 
XG-mode.  Read below for more of what my code would do.

> > In other words, GS-mode hardwares only use 128 banks of
> 128 instruments for any particular "hardware family". 
> That's a limitation of using only MSB (7-bit number) for
> limiting bank selection.
> >
> > Yamaha XG hardwares, on the other hand use the more
> logical ordering of bits in the 14-bits numbers.  They
> use combination of MSB and LSB to signify specific banks,
> including drum banks.  Which allows for addressing
> fuller range of [16384 banks] x [128 instruments].  Of
> course, some numbers may have already been used by older
> hardware, and for backward compatibilities, some of those
> numbers may be avoided for the time being.  But still,
> much more number of banks can be used in XG-mode.
> >
> > Not only that, MIDI-2 instruments of more recent years,
> all use the combination of MSB and LSB for bank selection.
> >
> > . . .

> Sorry for ripping the above out of context. The wBank number
> in the text 
> above, specifically refers to the saved number in the
> soundfont file, 
> rather than a calculation based on bank MSB and bank LSB.
> The wBank number is 128 (that is 128 zero based, i e
> 10000000 in binary) 
> for percussion, which gives up to 128 different kits given
> different 
> wPresets. I have also verified, with Swami, that that's how
> the big 
> fluid-soundfont-gm and fluid-soundfont-gs soundfonts are
> constructed.
> Do you have other soundfonts that work differently?
> So, the question of how to map the 14-bit number used in XG
> (and 
> MIDI-2?) modes, to the Soundfont's wBank number, is still
> the tricky 
> issue here. That is, with your patch in, I thought we had
> come up with 
> something that worked reasonably well.
> // David

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.

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.

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 

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.

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.  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.  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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]