Extend MIDI auto connect #1023
Extend MIDI auto connect #1023
Conversation
Context: ticket FluidSynth#414 The alsa_seq driver creates multiple ports (N/16) for N="synth.midi-channels", each mapped to synth channels: port*16+channel. This is already implemented. When the "midi.autoconnect" is specified, instead of subscribing only the last created port, all ports are sequencially subscribed to each available external MIDI inputs. When the last port has been subscribed, the next subscription starts again from port 0.
|
I'm not familiar with alsa_seq or alsa_raw driver, so would you please teach how the auto connect future is intended to behave from a musician user point of view. Assuming the following setup: 1)The synth system having 2 physical MIDI inputs (i.e device 1, device 2) feeding a single fluid synth instance with 16 MIDI channels(0 to 15). 2)The musician connect 2 MIDI keyboards , both transmitting on MIDI channel 0. With "auto connect" set to on, does the alsa_seq (or alsa_raw) driver redirect the 2 MIDI keyboards to the fluid synth's MIDI channel 0 input ?. What happens with auto connect set to off ? Is there really 2 distinct alsa MIDI driver in fluidsynth library ?. Sorry for my ignorance. |
ALSA sequencer provides virtual MIDI ports, each one supports a maximum of 16 channels. When the user sets "synth.midi-channels" to a value greater than 16, then additional virtual ports are created by the alsa_seq driver. If the value of synth.midi-channels" is the default (16), then only a single MIDI IN port is created by the alsa_seq driver. The user may connect both device1 and device2 to the single port, and ALSA merges both MIDI streams into one. No mapping will be performed (the synth receives the events exactly as they have been generated). When the value of synth.midi-channels" is for instance 32, the alsa_seq driver creates two MIDI ports. The user may connect device1 to the first port and device2 to the second port, by hand (using the console command This was already implemented in the alsa_seq driver, and nothing changed on this area with my patch.
Before my patch, all external devices were connected to the last MIDI IN port, applying the same mapping to all events. For instance, when synth.midi-channels is 32, then 2 MIDI IN ports are created. If the user has 3 controllers: device1, device2 and device3 and nothing more, then autoconnect will do:
The user needs to use an external connection tool. He may connect every controller to the first MID IN port, or not. The mappings are associated to the MIDI IN ports anyway. It doesn't matter if he uses autoconnect or does the connections by hand in relation to the MIDI channel mappings.
Yes. The alsa raw MIDI driver in Linux is like the winmidi driver. It has no virtual MIDI ports, and the driver has to open the MIDI devices, read events from them, and close the devices when finished. The alsa sequencer MIDI driver is totally different, more like the CoreMIDI driver in macOS providing virtual MIDI ports, and virtual cables (MIDI routing). |
…spected in channel mappings
|
Thanks Pedro, very nice explanations about alsa_seq (virtual ports) and alsa_raw behaviour !.
Ok, that means that device1 MIDI streams on Channel x are merged with device2 MIDI streams on Channel x (with x in the range: 1..16). If 2 musicians play at the same time on both devices, this could lead in MIDI streams conflicts. Does I understand well ? |
Of course, that is something expected. And that is why each musician should use different MIDI channels in that scenario. There are 16 MIDI channels, and each MIDI controller should allow to select the base channel. And to provide more flexibility, the Fluidsynth synthesizer has a maximum of 256 MIDI channels, that you may request using the setting "synth.midi-channels" that you choose to ignore. What are you telling me? That every MIDI merge box in the market is wrong because doesn't solve this problem that comes from the very deep guts of the MIDI 1.0 specification? |
|
As already said I am not familiar at all with ALSA stuff. I have found your explanations very useful. I just needed your confirmation about virtual ports. Thanks. |
This is a preliminary revision of the ALSA Raw MIDI driver, implementing the enumeration of Raw MIDI devices. The list is retrieved once, before the actual driver is created, and it is stored as options in the setting "midi.alsa.device".
|
Kudos, SonarCloud Quality Gate passed! |
|
This pull request introduces 1 alert when merging 906ecb6 into 015c6af - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
I really hoped that some more people would comment on those changes. Anyway, fluidsynth 2.3.0 is about to come and I would really like to have those change in. I need to make a decision which way to go forward. In the past days I had a look at them again and I have to admit that the mergebox setting suggested by @jjceresa did not convince me. Therefore, I will apply Pedro's proposal with this PR. If need be, we can think about any mergebox-like settings later. But for the moment, Pedro's suggestion seems to be more straightforward.
There are a few issues in your PR though. E.g. calling alloca in a loop. I will take care of them. Anotherone below.
|
I'm afraid I don't have time right now to work on this, sorry. |
|
Kudos, SonarCloud Quality Gate passed! |
midi.alsa.devicewith available devicesFor full context, please see discussion in #414.
Before this patch, all external devices were connected to the last MIDI IN port, applying the same mapping to all events.
After the patch, the external devices are connected in order to each MIDI IN port. When there are more devices than MIDI IN ports, the connections are distributed among all MIDI IN ports, sequentially.
For instance, when
synth.midi-channelsis 32, then 2 MIDI IN ports are created. If the user has 3 controllers: device1, device2 and device3 and nothing more, then autoconnect will do:MIDI IN port 1 connected to device1 and device3.
MIDI IN port 2 connected to device2.