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 #65


From: David Henningsson
Subject: Re: MIDI Bank Select proposal (was Re: [fluid-dev] Re: Son of ticket #65)
Date: Sun, 08 Aug 2010 12:28:56 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6

2010-08-04 23:31, Pedro Lopez-Cabanillas skrev:
> 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!
>>
>>> MIDI Bank Select messages are Control Change #0 (MSB) and CC#32 (LSB)
>>> [4]. Up to FS-1.0.9, the behavior was that when a CC#0 message was
>>> received, the value was used as the channel bank number. If a CC#32 was
>>> received later, the bank number was recalculated as MSB*128+LSB and the
>>> result used as the new channel bank number. The bank number is not
>>> immediately used, but reserved until a Program Change message is
>>> received, and then applied to select a sound preset from the loaded
>>> soundfonts.
>>
>> I remember finding that inconsistent, i e it mattered in which order MSB
>> and LSB were received. I think that was one of the reasons for changing it.
> 
> 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.

And what my change was supposed to fix, and also did so, was that the
combination "MSB, then LSB, then Program Change" always gave the same
result as "LSB, then MSB, then Program Change". I'd like to keep it that
way if possible, and I assume you agree.

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

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

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

// David



reply via email to

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