Re: [fluid-dev] Soundfont banks

[jimmy]

--- On Mon, 7/16/12, David Henningsson <address@hidden> wrote:

> Just a question here: What soundfont do you run these files
> with? Is 
> there an XG soundfont out there (or maybe even lots of
> them?), and if so 
> - how is that soundfont constructed? How does it squeeze
> XG's drum banks 
> and melody banks into the 128+1 bank numbers that the
> soundfont 
> specification offers?
> 


You can use any standard GM soundfont to try it.  Running FluidSynth in XG-mode 
already has the soundbank/drumbank fallback scheme in place.  So any 
soundbank/drumset that isn't found, it reverts to using the GM 
soundbank/drumset.

Poor-man's XG, or at least a simplest starting point.  Of course, different 
drumbanks will have different instrument-note mapping.  Similarly, in hardware, 
same instrument in different soundbanks will sound differently because they 
would use different special effects parameters on the same sound samples.  Some 
funky drumset mapping may sound wierd because the same note in that drumset may 
be mapped to a whistle in default GM standard drumset, for example.  To get 
that in FluidSynth, custom soundfonts would be needed.

Note that it does print out a warning/info on the Fluidsynth console 
(commandline output) when it could not locate a soundbank number (in decimal).  
This way, folks can see what particular soundbank is expected by that specific 
XG-MIDI file (or XG hardware), should they want to do some custom soundfont 
mapping.  Again, the number being used and printed out right now is truncated 
to 7-bit (CC32 only).  Fluidsynth needs my rejected patch to properly print the 
full 14-bit (CC0/CC32) number (used by the XG-MIDI file, or XG-harware) 
correctly.


Using the basic GM soundfont for XG-mode is similar to my other patch in 
GM-mode when an instrument is not found in some soundbank, it reverts to using 
the same instrument number in the default soundbank (bank=0).  Prior to that 
patch, Fluidsynth simply ignored that instrument, no sound would be heard at 
all for that channel until an exact instrument requested was found (some sound 
banks only have a few instruments mapped).  A live reset command (while 
continue playing) would of course set that instrument to piano, should one 
tries to at least hear something is playing on that channel (or determine if 
some MIDI events even get to that channel at all).

The fallback scheme, I believe is vailable in both XG and GS in some way.  I 
also believe that is what "all" GM hardwares do, too.  This is the rationals 
around the original request for my patch in "GM-mode fallback" instrument 
lookup.  Try any hardware keyboard, or hardware sound module, connect to it via 
MIDI cable and request an invalid CC0/CC32 and progChange request, it would 
never "silence" that channel (as FluidSynth did at that time).  It most likely 
will keep the current instrument, or use some fallback mapping of sort.

Those patches I wrote for XG-mode already in FluidSynth simply uses the 
particular resources if they are available, if not it would try to do a 
reasonable cascading substitution to some equivalence instruments/drumsets 
within that GM/XG mode.  I had previously explained these instrument mapping 
(in GM-mode) back when Josh/Element Green was applying such patches, as well as 
CC0/CC32 mapping when I submitted the XG-related patches.

In XG-mode for XG-hardwares, if I remember correctly, they use CC0=121/CC32=0 
as their default/fallback soundbank (don't remember if this is written to use 
that before using the GM-default in FluidSynth XG-mode).  Such soundbank sounds 
much better than the GM-mode default soundbank in those hardwares.  So they can 
claim that XG harwares/softwares sounds much better than GM sounds.  Pure 
marketing B.S, it's their mapping that make GM-mode sound bad in those 
hardwares/softwares.  GS-hardwares do similar things, I believe.

Jimmy