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

[Elimar Green]

Actually I take that back, about it sounding good..  It seems like
adding a MIDI mode which requires manual assignment of that value,
without proper SYSEX handling, will likely lead to many MIDI songs not
working properly (like if a user is playing multiple MIDI files which
are of different modes).  The 1.0.9 logic, should handle most MIDI
modes, in regards to bank switching.  Personally I think its a better
option at this point.  The only thing that logic doesn't do, is
properly ignore certain messages.  Messages which are unlikely to be
sent in their respective modes anyways, though I admit I'm not sure
how many MIDI files might be out there which don't follow that rule
(for example send LSB MIDI messages though they expect them to be
ignored).  I suppose you could still add the setting, but have a
special "auto" or "compatibility" mode which follows the 1.0.9 logic.
The user could then force a particular mode with that setting.

Just some thoughts.  I'll leave it up to you guys to decide ultimately
how it gets implemented.

Regards,
Elimar

On Wed, Aug 11, 2010 at 12:34 PM, Elimar Green <address@hidden> wrote:
> On Mon, Aug 9, 2010 at 11:01 PM, Pedro Lopez-Cabanillas
> <address@hidden> wrote:
>>
>> I agree that we can leave the SYSEX stuff for a future release, avoiding the
>> risk of spend too much time implementing and testing this feature. In
>> addition to your code, I've included similar functionality in kmidimon.
>>
>> I disagree with simply reverting to 1.0.9, because adding a new
>> setting "midi.bank-select" with several options is easy enough, and may be
>> needed for accurate playback of different songs. In my opinion, the default
>> should be the awe32 mode, as recommended by the appendix 1 of the SF2
>> standard.
>>
>
> Sounds good.  Does it make sense to have separate midi.bank-select and
> a midi.mode setting though?  Why not just make it midi.mode and then
> we can add additional functionality on to it in the future?  That was
> how it had been implemented previously in SVN.
>
>> Regards,
>> Pedro
>>
>
> Regards,
> Elimar
>