fluid-dev
[Top][All Lists]
Advanced

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

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


From: Elimar Green
Subject: Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
Date: Thu, 5 Aug 2010 21:57:13 -0700

On Wed, Aug 4, 2010 at 2:31 PM, Pedro Lopez-Cabanillas
<address@hidden> wrote:
> On Wednesday, August 4, 2010, David Henningsson wrote:
>> 2010-08-03 22:48, Pedro Lopez-Cabanillas skrev:
>> > [Sorry, this is a bit long...]
>>
>> I'm glad you took the time to sort it out!

I second that.  Thanks for taking the time to explain it better.  I
now get what the issue is.

>
> No, MSB and LSB are CC messages that come in any order. The restriction is
> that the CCs must be received before the Program Change, and are only applied
> at that moment. In other words: sending bank select messages without a
> Program Change has no effect, in any of my MIDI hardware instruments.
> FluidSynth should behave the same.
>
>> > 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.
>

That is only for General MIDI (GM) compatibility though.  If I
remember correctly, the actual quantity in a SoundFont file is a 16
bit number for bank.  So theoretically you could assign any 16 bit
quantity as a bank number in a SoundFont file, though I would guess it
only really makes sense to limit it to a 14 bit quantity if you want
to actually be able to select it using standard MIDI messages.

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

I think it actually needs to work a bit differently from what you both
described.  It should be done as it was in 1.0.9.  There was a bit of
overhauling for 1.1.0 and I think the bank behavior got
unintentionally changed, by yours truly.

The previous behavior worked as so (from examining the 1.0.9 code base):
- Each channel keeps track of the last MSB value and the current BANK value
- If an MSB is received: MSB = value and BANK = value
- If an LSB is received: BANK = MSB * 128 + LSB

That should do the trick and work in most MIDI modes, minus the GM
mode where bank selection should be ignored.


> 1.1.0 was totally broken for bank select messages.
>
> Regards,
> Pedro
>

Cheers!

Elimar



reply via email to

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