Re: [fluid-dev] Re: Patch for channel_type, also XG drum-channel autoswitch

[Pedro Lopez-Cabanillas]

On Friday 11 February 2011, jimmy wrote:
> 
> Oops, sent with wrong subject line, before I finished.  I wrote more beyond 
> last message, so read this message instead of last.
> 
> 
> 
> --- On Thu, 2/10/11, "Pedro Lopez-Cabanillas" <address@hidden> wrote:
> 
> > > So bank numbers above 128 usually make no sense, which
> > is why MSB is 
> > > ignored for XG (and why MMA style is not the
> > default...). We're kind of 
> > > stuck between sf2's standard and XG's standard, and
> > need to figure out 
> > > how to mediate between them.
> > 
> > Agreed. This issue has been already posted and discussed in
> > this list, so here are some relevant excerpts and pointers.
> > The SoundFont2 PHDR sub-chunk has this header structure:
> > 
> > struct sfPresetHeader
> > {
> >         CHAR achPresetName[20];
> >         WORD wPreset;
> >         WORD wBank;
> >         WORD wPresetBagNdx;
> >         DWORD dwLibrary;
> >         DWORD dwGenre;
> >         DWORD dwMorphology;
> > };
> > 
> > Where wBank is a 16bit field, like wPreset. But the
> > specification states the 
> > range from 0 thru 127 for both the wBank and wPreset.
> > Document "sfspec21.pdf", page 27:
> > 
> > "The WORD wPreset contains the MIDI Preset Number and the
> > WORD wBank contains 
> > the MIDI Bank Number which apply to this preset. Note that
> > the presets are 
> > not ordered within the SoundFont compatible bank. Presets
> > should have a 
> > unique set of wPreset and wBank numbers. However, if two
> > presets have 
> > identical values of both wPreset and wBank, the first
> > occurring preset in the 
> > PHDR chunk is the active preset, but any others with the
> > same wBank and 
> > wPreset values should be maintained so that they can be
> > renumbered and used 
> > at a later time. The special case of a General MIDI
> > percussion bank is
> > handled conventionally by a wBank value of 128. If the
> > value in either field 
> > is not a valid MIDI value of zero through 127, or 128 for
> > wBank, the preset 
> > cannot be played but should be maintained."
> > 
> > http://connect.creativelabs.com/developer/SoundFont/Forms/AllItems.aspx
> > 
> > Regards,
> > Pedro
> > 
>
> For soundfont bank number, what's wrong with creating some virtual sound bank 
> look up scheme beyond 128, somehow...  eventually...  in XG mode...  or some 
> Fluidsynth enhanced mode?  Remembering MSB is the first step anyhow.
>
> Just because GM say channel 10 is drum doesn't mean it should be the only 
> one. Or, that there are 128 banks in GM, doesn't mean we can't have, or use 
> more than 128.  Same goes for soundfont specs.  Aim high, don't go for the 
> bare minimum.

I'm not against more functions and modes in FluidSynth, but our project 
description says: "FluidSynth is a real-time software synthesizer based on the 
SoundFont 2 specifications." First, we should make it compliant with the 
published standard, by default. Then, there may be whatever extensions and 
enhancements chosen by special modes, if we want.
 
> Try to browse through various Cakewalk .ins instrument defintion files, or 
> calculation formulae for Yamaha instrument banks.  They use that to talk to 
> those devices bi-directionally (record and/or playback), I think.  They make 
> use of the bank change MSB's, not throw them away.  I am not a Cakewalk user, 
> only glancing through bits of info.
> 
> Rosegarden also use some instrument description file to talk to specific midi 
> devices.
> 
> With Timidity configuration file, one can use a virtual bank mapping to 
> select a specific bank in one soundfont to override another bank in a 
> different soundfont.

Cakewalk and Rosegarden are MIDI sequencers, not specialized in SoundFonts or 
in Software synthesizers. Many people use these sequencers to work with 
different types of hardware synths. 

Timidity is a soft-synth, and it is capable of loading SoundFonts as well in 
addition to Gravis patches. It needs the configuration file to load and map 
Gravis patches, something that can be avoided when you use SoundFonts with it.
 
> How about Fluidsynth uses a configuration file to map some chunk of 
> 128-LSB-bank-set to one of the MSB number?  In other word, using multiple 
> GM-soundfonts files, each would have a separate MSB number.  What's wrong 
> with that?  Nothing.  If anything, it opens up a whole new world of MSB to 
> us.  And can work fine with XG MSB's, too.

Very well. If you really want to go further around this proposal, please take 
also a look to the API functions fluid_synth_set_bank_offset() and 
fluid_synth_get_bank_offset(). They are used by QSynth.

This concrete feature may be a good idea, but it is not what we are debating. I 
mean that you can propose new features, elaborate your ideas and post your 
proposal in the mailing list or in the tracker to be discussed. Once the new 
feature plan is mature enough you can create a patch to implement your ideas 
and if it is well written it will be included in the repository. To implement 
your proposal you may need to redefine the internal bank numbers and provide a 
mechanism to map several concurrent SoundFonts with banks and patches into the 
internal synth according to some configuration settings. Nothing to object.

Your mistake is to start the process by the end, coding some decisions and 
behaviors first and then justifying it with promises of hypothetical features.

Regards,
Pedro