--- On Mon, 7/16/12, David Henningsson <di...@ubuntu.com> 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
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev