fluid-dev
[Top][All Lists]
Advanced

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

Re: [fluid-dev] MIDI bank select problems


From: Element Green
Subject: Re: [fluid-dev] MIDI bank select problems
Date: Fri, 29 Nov 2013 12:31:37 -0700

On Thu, Nov 28, 2013 at 11:53 PM, Chris Robinson <address@hidden> wrote:
On 11/28/2013 08:05 PM, Element Green wrote:
Good idea to read through the archives..  I also did this and came up with
a thread which occurred around the date when the code was checked in for
the synth.midi-bank-select option.  I came up with this email in particular
from Pedro which describes the MMA mode:
https://lists.nongnu.org/archive/html/fluid-dev/2010-08/msg00046.html

Hmm, odd. According to that, Creative thinks MMA mode should be CC0*128 + CC32, but neither the GM1 or GM2 standards define this behavior. In fact, GM1 doesn't have bank select messages, and GM2 hadn't been adopted yet when the SoundFont (1 or 2) stuff was created. Looks like this is just what Creative thought the MMA was going to standardize on, but it's really an XG mode that doesn't ignore CC0 as part of the bank number.



The original MIDI standard pretty much spells that out, though I think there was some confusion around it leading to divergent vendor standards.  CC 32-63 are supposed to be the least significant bytes and CC 0-31 the most significant bytes of 14 bit controller values.

 
Instead, the MMA went a different way with GM2. CC0 selects a channel type (120 = percussion (only allowed on channels 9 and 10), and 121 = melodic), and CC32 selects a bank (must be 0 on percussion channels).


I don't really see it as a "different way" in respect to MIDI, but more in comparison to the other instrument mapping standards.  Interpreting CC0 and CC32 as MSB/LSB of a 14 bit number (as the GM2 article on Wikipedia also says), then GM2 percussion is on bank 15360 and the melodic banks start at 15488.  While SoundFont files physically can store up to a 16 bit value for bank numbers, the specification says it should be limited from 0-127 for melodic banks and 128 is for percussion.  So it seems like if a GM2 mode were to be added to FluidSynth, the actual bank numbers would be set to the usual SoundFont convention, rather than trying to conform SoundFont files to the GM2 spec.  So a GM2 SoundFont would contain melodic instruments and variations on the various banks and percussion presets would still be on bank 128, as usual.  A "gm2" mode could be added to FluidSynth which would respond to a CC0 MSB bank value of 120, by assigning percussion bank 128 and ignoring the LSB.  Or in the case of CC0 MSB being 121, CC32 LSB would be used to select the bank number.



I'm personally curious though, why you chose GM2 as your
MIDI variation of choice?

Mainly because GS and XG are vendor-specific, while GM2 is about as standard as you can get here. And unlike GM1, GM2 allows switching channel 9 to act like a normal channel, which I feel adds an important bit of flexibility in letting the app developer worry about where and how instruments can be mapped in a custom soundfont.



What becomes standard is what is wide spread and adopted, whether its defined by a vendor or MMA.  SoundFont for that matter is a vendor specification.  I haven't seen many GM2 SoundFont files around and I'm not sure how many MIDI files there are out there, perhaps someone can elighten me on this.  I agree though, that having more flexibility in regards to percussion channels is good.  Currently the only MIDI mode which FluidSynth supports which has that feature is XG mode (bank 120-127 selects percussion, anything else is melodic).

 
In reading that above email, however, it seems Creative says SF2 synths must use GS mode by default, and I'm aiming for OpenAL Soft's MIDI extension to provide an SF2-compatible synth so developers can know what they're working with. So I guess I shouldn't try forcing GM2 on initialization.


Still, that leaves the question of how to allow apps to use the bank/instrument they want on channel 9. I suppose the "correct" way would be for them to send a GM2 On sysex message {0x7E, 0x09, 0x03}, as described here <http://www.midi.org/techspecs/midimessages.php>, if they want it. But I don't think FluidSynth recognizes that.

The other possibility is that I could watch for CC32 being set to 120 or 121 on channels 9 and 10 in OpenAL's MIDI event handler, switching the channel to be percussion or melodic accordingly via fluid_synth_set_channel_type, and leaving CC0 to be the bank number as per GS mode (basically reversing the bytes as described in GM2).

Supporting the GM2 On sysex message sounds like the better option to me, as its the more standards-compliant way. Watching CC32 is also a possibility, but I'd like to avoid custom behavior if I can.


I had worked on some code which selected the MIDI mode based on SYSEX messages, but I think it was abandoned at some point, can't remember why.  Perhaps it was the complication of other caveats in regards to MIDI modes (not just bank selection).  Seems like SYSEX mode selection would be a good thing to have for other MIDI modes as well, though.

At any rate, I think such logic should be in FluidSynth and not left up to your specific application to handle.  How I see that functioning is through a couple of additional settings.  Too bad synth.midi-bank-select isn't called synth.midi-mode or something more general.  Either the midi-bank-select setting could be used for the MIDI mode or another setting could be added which controls behavior of everything non bank select related and midi-bank-select gets another value called "mode" which uses the current midi-mode setting.  Another setting could be added like "synth.midi-mode-sysex" which can be used to disable MIDI mode selection by SYSEX messages.

At any rate, your application would benefit from such additions without any changes, so I would think you would just proceed using the default MIDI mode that FluidSynth uses, leaving such MIDI mode logic up to a future FluidSynth release.

Best regards,

Element Green




reply via email to

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