Alsa Midi port name ambiguity trouble

[Impostor]

With kernel 5.11 and below, the midi out ports of my midi keyboard are called:

Code: Select all

aconnect -i
.......
client 24: 'Keystation 49 MK3' [type=kernel,card=2]
    0 'Keystation 49 MK3 MIDI 1'
    1 'Keystation 49 MK3 MIDI 2'

Yet with kernel 5.13 and 5.15, the ports are called:

Code: Select all

~$ aconnect -i
......
client 24: 'Keystation 49 MK3' [type=kernel,card=2]
    0 'Keystation 49 MK3 Keystation 49'
    1 'Keystation 49 MK3 Keystation 49'

As you can see, both ports get assigned the exact same name with the newer kernels, whereas previously they differed. This seems to give a problem in both QJackCtl and MusE when trying to make connections.

In QJackCtl, when selecting the Keystation as an alsa output client in the Patchbay, I initially get the choice between two plugs (of the same name: Keystation\ 49\ MK3\ Keystation\ 49), but after selecting any one of them, the other disappears.

Strangely enough, in the graph window, the output ports -do- have different names (0:Keystation 49 MK3 MIDI 1 and 1:Keystation 49 MK3 MIDI 2), and -both- are connected when in the patchbay I connect the Keystation output socket (with just the single plug selected) to a midi input socket.

Also, although in the graph I seemingly -can- connect the two ports independently, creating a new patchbay config with the graph as basis, and subsequenly activating it, connects both output ports to the same inputs.

This should give no problems perhaps (maybe these ports are not meant to be separately connected, ever) were it not for the fact that in MusE, while apparently properly setting up the connections, no midi activity can be discerned at all.

Code: Select all

aconnect -l
......
client 24: 'Keystation 49 MK3' [type=kernel,card=2]
    0 'Keystation 49 MK3 Keystation 49'
	Connecting To: 129:0[real:0], 131:0
	Connected From: 129:0
    1 'Keystation 49 MK3 Keystation 49'
	Connecting To: 129:0[real:0], 131:0
	Connected From: 129:0
client 131: 'MusE' [type=user,pid=2302]
    0 'MusE Port 0     '
	Connecting To: 129:0[real:0]
	Connected From: 0:1, 129:0, 24:1, 24:0

^^Scroll for the complete text^^

I -think- this has to do with the fact that the two ports of my midi keyboard get assigned the same name with the newer kernels. On the older kernels where they get different names, I get no midi trouble at all.

Luckily, there is a simple work-around:

In QJackCtl, connect the Keystation to Alsa Midi Through, and connect Midi Through to MusE. Then it all works fine. It's still a work-around though, and not how it should ideally be done, imo.
Or, one could just use Jack Midi of course...

I'm also not sure if this problem is exclusive to MusE or not, but standalone fluidsynth, and also pianoteq, at least still seems to work just fine without rerouting midi over midi-through.

Thanks for reading:)
(I wanted to include some screenshots, but must first figure out how. But I don't think they are needed to understand the text anyway)
EDIT: I use Muse 4.1 appimage, and QJackCtl 0.9.7 appimage, on linux Mint 20.2

[Impostor]

In short, see attachments

[Impostor]

These are the MusE settings in the nonworking config:

[Impostor]

QJackCtl behaviour:

Manually drawing the connections as in lower figure, saving as new patchbay, and activating, results in connections in upper figure:

[Impostor]

And, manually setting any of the configs below, persistent or not, give no midi activity in MusE either:

EDIT: The upper config -does- result in Midi activity, but Port 1 sends only commands from the transport buttons (DAW specific??).

[j_e_f_f_g]

Yep, they finally did it. They wrecked MIDI configuration on Linux the same way they did audio configuration.

It was only a matter of time.

[Impostor]

Yep, they finally did it. They wrecked MIDI configuration on Linux the same way they did audio configuration.

It was only a matter of time.

I'm curious though if other people have the same issue. Kernel 5.13 is out a while already. Otherwise it could just be a quirk of my specific setup..

[bluzee]

Test a 5.19 kernel and if the problem is still there file a bug report.

[Impostor]

Test a 5.19 kernel and if the problem is still there file a bug report.

If only that kernel was available in the repository. I've never even built a piece of software from source. I don't think starting with the compiling of kernels is such a great idea:)

[folderol]

I'm not having any problems here with kernel 5.18 in devuan testing, but having said that I don't have any kit with multiple MIDI ports.

[Impostor]

I'm not having any problems here with kernel 5.18 in devuan testing, but having said that I don't have any kit with multiple MIDI ports.

Which makes me wonder why my midi keyboard has two out ports (via a single usb cable connection) in the first place. Its manual says nothing at all about it.

Edit: maybe for transport control or something..

[Impostor]

I'll be damned:

Connecting the midi ports directly to MusE does indeed result in -transport- midi signals being sent to the midi track. I can't control MusE's transport with it, but I -can- play some piano notes with the transport buttons, lol!

Something's fucked up the wiring all right! I seriously think it does have something to do with the ports being given identical names.

[Impostor]

Okay, summing up:

manually connecting the Keystation's alsa ports to Muse in the graph window of QJackCtl has the following result:

-Keystation port 0 directly to MusE: no midi activity in MusE.

-Keystation port 0 via Midi Through to MusE: works fine.

-Keystation port 1 directly to MusE: can play piano with the transport buttons on my keyboard, but not with the piano keys.

-Keystation port 1 via Midi Through to MusE: can play piano with the transport buttons on my keyboard, but not with the piano keys.

-Both Keystation ports directly to MusE: can play piano with the transport buttons on my keyboard, but not with the piano keys.

-Both Keystation ports via Midi Through to MusE: works fine.

The above is true with kernel 5.15. Also, with this kernel, the available midi devices tab in MusE shows the Keystation as a single device, whereas with kernel 5.11, where all is fine and well, the Keystation shows up as two devices. See screenshots.

[Linuxmusician01]

I'm not having any problems here with kernel 5.18 in devuan testing, but having said that I don't have any kit with multiple MIDI ports.

Which makes me wonder why my midi keyboard has two out ports (via a single usb cable connection) in the first place. Its manual says nothing at all about it.

Edit: maybe for transport control or something..

Maybe one is USB Midi and the other "good old" Midi via a 5 pin DIN cable.

Maybe one is the left part of the keyboard and the other the right part. Remember, back in the day on very expensive synthesizers you could play 2 patches at the same time. For example a bass patch at the right-hand side and a "solo" patch at the left side. Read the manual that came w/ your keyboard. Maybe you accidentally (de)activated one or the other.

[j_e_f_f_g]

Maybe one is USB Midi and the other "good old" Midi via a 5 pin DIN cable.

MIDI commands are the same regardless of the hardware protocol. There's no difference between the MIDI commands over USB versus a DIN cable versus an ethernet cable, or anything else. So there would be no reason to duplicate the signal.

Maybe one is the left part of the keyboard and the other the right part.

That's usually done by simply using 2 different MIDI channels.

If I had to guess what's happening here is that one USB line is meant to carry incoming MIDI data to play musical notes, and the other line is meant to either be used to send sysex data for a patch editor. Or, it could be a second MIDI port, for a total of 32 MIDI channels.

MAudio either use generic chips (not made specifically for their products only) in their products, or if they do have custom chips made, they usually have a "generic version" which can be used in more than one product model (to save production costs).

So my guess is that the Keystation 49 MK3 is using a generic controller that supports 2 USB-MIDI lines, but the second one just isn't connected to anything. The linux generic USB-MIDI driver is handling the 49, but doesn't have a "quirk rule" that hides this "ghost MIDI input" from apps. So apps list it, and can be set to read from it, but no data ever appears. (Hence why the OP is not noticing it having any effect).