extended auto connect #414

[pedrolcl]

For context, please see discussion in #414

Drivers:

• [x] alsa_seq
• [ ] alsa_raw
• [x] winmidi

[jjceresa]

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.

[pedrolcl]

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

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 aconnect, or one of the graphic connection tools available). The events sent by device1 are received by the synth on channels 1-16. The events sent by device2 are received by the synth on channels 17-32. The mappings are associated to the virtual MIDI ports.

This was already implemented in the alsa_seq driver, and nothing changed on this area with my patch.

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

Before my 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-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:

• MIDI IN port 1 connected to device1 and device3.
• MIDI IN port 2 connected to device2.

What happens with auto connect set to off ?

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.

Is there really 2 distinct alsa MIDI driver in fluidsynth library ?. Sorry for my ignorance.

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

[jjceresa]

Thanks Pedro, very nice explanations about alsa_seq (virtual ports) and alsa_raw behaviour !.

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.

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 ?

[pedrolcl]

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?

[jjceresa]

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.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

10.6% Coverage
0.0% Duplication

[lgtm-com[bot]]

This pull request introduces 1 alert when merging 906ecb6ef61701534fb84e424605d13a72130486 into 015c6af52d8233eaae556242b5200290558ba415 - view on LGTM.com

new alerts:

• 1 for Call to alloca in a loop

[pedrolcl]

I'm afraid I don't have time right now to work on this, sorry.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

12.3% Coverage
0.0% Duplication