Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)

[Pedro Lopez-Cabanillas]

On Sunday, August 8, 2010, David Henningsson wrote:
> >>> SF2 (SoundFont) files (like GeneralUser, FluidR3,...) have bank numbers
> >>> < 127 for melodic sounds and 128 for Drum kits, as recommended by the
> >>> SoundFont specification [5]. It is necessary to map the MIDI Bank
> >>> Select numbers to the SF2 bank numbers, because they won't always
> >>> match. The sf2 spec says that "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."
> >
> > I want to remark the above quotation from the SF2 specification. SF2 bank
> > numbers for melodic channels are numbers in the range 0 to 127, 7 bits.
>
> 128 for wBank. I saw nothing about that in your proposal, or if the drum
> MIDI channel should be handled in another way than the rest of the
> channels, could you elaborate on that?

Melodic channels means all channels except the drum channel. Channel#10 is the 
MIDI drum channel number reserved in the GM specification, and all the other  
extensions. SF2 Bank 128 is only intended to be applied on the MIDI drum 
channel, not on melodic channels. It is well explained in the SF2 
specification and appendix documents.

The test case I've proposed (March in D major by Christian S. Collins played 
with FluidSynth 1.1.x) is the illustration on how wrong is the result when 
you don't honor this separation between melodic and drum channels. 

> >>> "Compatibility mode" with the following rules, if we don't know which
> >>> standard to follow: 1. If MSB is received alone, or with LSB=0, then
> >>> use MSB as the soundfont bank number. This is probably going to work
> >>> with most GS songs.
> >>> 2. If LSB is received alone, or with MSB=0, then use LSB as the
> >>> soundfont bank number. This is probably going to work with most XG
> >>> songs. In any other case, we need to know if the song/player follows
> >>> the GM, GS or XG standards, either when a SYX message is received, or
> >>> with a setting.
> >>>
> >>> The proposal is that this "Compatibility mode" should be the default.
> >>
> >> So, how about:
> >>
> >> banknum = LSB == 0 ? MSB : MSB*128 + LSB ?
> >
> > banknum can be a number from 0 thru 16383 from that formula, 14 bits.
> > The bank number from standard compliant SF2 files is a number from 0 to
> > 127, 7 bits. You can't match SF2 bank numbers with your banknum.
> >
> > If you want to be compatible with most SF2 files, you need to avoid the
> > formula (MSB*128 + LSB) completely.
>
> Except for wBank, which needs at least 8 bits to specify. Hmm, that
> isn't possible to specify in my proposal either.
>
> >> ...regardless of order received? That way, 1. and 2. work as you
> >> suggest, and "any other case" works as before - I believe, both as 1.1.0
> >> and 1.0.9 worked, right?
> >
> > 1.1.0 was totally broken for bank select messages.
>
> Totally broken? No. Incompatible with GS, yes, but that was because the
> GS spec is not publicly available, and I didn't find the wikipedia
> article on it (or didn't read it carefully enough).

Roland synth handbooks can be downloaded freely, and they usually contain the 
relevant information. For instance, any Roland Sound Canvas manual. I have 
one of them (an old SC88).
http://en.wikipedia.org/wiki/Roland_Sound_Canvas

> Here's another thought. This seems difficult to really get right in all
> cases, and needs GM/GS/XG/GM2 sysex detection to give the best result.

Yes, we should include in this release:
* a new setting, specifying a default Bank Select mode.
* recognize some SYX messages, changing the Bank Select mode accordingly.
* process CC#0 and CC#32 taking into account the Bank Select mode.

> How about we release 1.1.2 now, list this as a known issue, and release
> 1.1.3 as soon as this is agreed, fixed and finished, with Sysexes,
> settings, and so on?
> If that then takes just a week - then we can release 1.1.3 just a week
> after 1.1.2. What do you think about that?

I don't agree with releasing 1.1.2 with this bug. If we need to delay the 
release date one, or two, or three weeks, it should be delayed. Why are you 
in a hurry?

Regards,
Pedro