Status of KeyLab mk3 & Analog Lab on Linux

[Bidinou]

This is probably a message in a bottle, but I dropped the following message to the Arturia support team

"Dear Arturia team,

I am the happy owner of a Keylab MK3 (regular).

Even if unsupported, it works almost perfectly under Linux.

I have a minor issue when using Arturia plugins on Linux (through WINE)

• the plugins work perfectly with low latency (WINE + wineasio + pipewire).

• my KeyLab works perfectly out of the box

• however, the plugins do not detect my MIDI keyboard as a Keylab MK3 but as a generic keyboard.

→ if I select the keyboard type manually in the Arturia plugins configuration, it works as expected but there are 2 problems :

1. I have to re-select “Keylab MK3” in the configuration each time I restart the plugin

2. the Keylab screen does not display any information / does not allow to select the instrument (in “Arturia mode”).

I am confident this is extremely close to working perfectly - as the Astrolab runs Linux. Would it be possible to unofficially either release the Linux version or at least force the plugin to use the Keylab screen ?

Thank you so much <3"

[Thorgal]

Hey Bidinou,

I wouldn’t hold my breath but it’s worth a try, if more linux users are pestering them, who knows ?

I would have added the following: the screen feedback with the mkii works, and I believe Analog Lab remembers the mkii when fired up again. So if it works with the mkii, why is it broken with mk3 ?

T.

[Tim.Arturia]

Hello.

I understand your frustration but we do not support Linux so I would not expect a lot from our support that must prioritize users that are using the officially supported platforms.

@Bidinou

as the Astrolab runs Linux. Would it be possible to unofficially either release the Linux version

That’s not that easy, the embedded versions of our plugins are quite different from the original desktop ones. It would require quite a lot of work to release Linux versions, even unofficially.

@Bidinou

or at least force the plugin to use the Keylab screen

I think you might be able to fix that issue in your wine setup.
The KL / AL integration works using midi, if you succeed to play notes with the controller, you may be able to fix the integration somehow. I’m no expert in this field so I can’t really point out what’s going on but I’m confident that it’s solvable.

Cheers !

[Bidinou]

Hi Tim,

thanks for your reply, much appreciated ! Hellos and congrats to the team for their hard work !

Hmm, I guess Linux support might be difficult to add as an afterthought, but maybe it could fit in a longer time roadmap ? Well, difficult to know if it would be worth financially, but it would make sense, given the uncertainties on the behavior of the GAFAMs in the coming years… And considering at long last Linux offers out of the box low latency audio + distro agnostic ways of distributing software.

Regarding the KL MK3 screen <> Plugin integration : does it use some kind of custom protocol that would require the Windows driver ? If we could figure out what is missing, maybe it could be fixed on the WINE side indeed

Thanks again,
take care

[Bidinou]

After making some random searches, I stumbled upon this :
https://linuxmusicians.com/viewtopic.php?t=25885

"I would like to share with you a small tool which may be helpful if you have trouble getting your MIDI devices recognized in Wine applications due to having ALSA-generated names.

Most MIDI-controllable software allows the user to choose from a list of devices, but some software just expects a certain device to appear with a particular name or property. The fact that ALSA usually generates different names than native Windows winmm would can cause issues here."

I don’t have the time to test right now, but maybe it is the reason why the detection does not work ? Anyone who could share the exact name of the device under Windows ?

[Tim.Arturia]

@Bidinou

Hmm, I guess Linux support might be difficult to add as an afterthought, but maybe it could fit in a longer time roadmap ?

Because I like Linux, I can only agree, but I’m not in charge of roadmaps

@Bidinou

does it use some kind of custom protocol that would require the Windows driver ?

No, only SYSEX.

@Bidinou

due to having ALSA-generated names

Here you go, indeed the MIDI name must be the same as on Windows to be working.
If you succeed to get the same controller MIDI name as on Windows, it will probably work !!

If it works, it would be great if you could share a little tutorial for other Linux users !

Cheers !

[Bidinou]

Hi ! I managed to substitute the peripheral name but it doesn’t seem enough.
I also need a “man_id” and “prod_id” from the “midiXXXGetDeviceCaps” structure.
I’ll try to dual boot on a Windows stick to figure that out.

Can any windows user make a screenshot of his MIDI settings in Analog Lab for instance ?

cheers !

[Thorgal]

From the github issue of this MIDI spoofing app, you could try “replace_man_id”: 65535, “replace_prod_id”: 65535, it seems that that’s what windows is using. I have no windows box here so I can’t check any of this though.

[Bidinou]

Tadaaa, it works !

Tutorial :

• Download winmm.dll from GitHub - SanderVocke/winmm_midi_rename: WinMM wrapper which enables rule-based modification of MIDI device properties. (releases on the right)
• Copy it to the directory containing the Arturia app
• Create a “midi_rename_config.json” text file containing the following :

{
"log": "midi_rename.log",
"popup": true,
"popup_verbose": false,
"rules": [
{
"match_name": "KeyLab 61 mk3 KeyLab 61 mk3 MID",
"replace_name": "KeyLab 61 mk3 MIDI",
"replace_man_id": 1,
"replace_prod_id": 102,
"replace_driver_version": 2560
},
{
"match_name": "KeyLab 61 mk3 KeyLab 61 mk3 DAW",
"replace_name": "KeyLab 61 mk3 DAW",
"replace_man_id": 1,
"replace_prod_id": 102,
"replace_driver_version": 2560
}
]
}

• start the Arturia instrument standalone
• That’s it ! The MK3 screen & buttons work as expected

Now, this works when starting the standalone version of an Arturia instrument. I have to check how to do it in a global way so that it also works with VSTs from DAWs.

[Thorgal]

Hey, nice!

I tried it as well, does not work at all. Which wine version and Analog Lab V are you using ?

EDIT: found the problem, copy-pasting from the forum introduces some subtle character differences, the double-quotes are not correct and misinterpreted by the json parser. The text file should have the usual straight double quotes, not the ones used in the forum font which for some reason is preserved in my emacs.

[Bidinou]

My fault, didn’t use the “pre-formatted text” tag. Fixed

BTW, I didn’t check, but maybe only replacing the name of the device is sufficient. I didn’t have the right name when I first tried (“MIDI” at the end of the label and not “MID”).

Now, remaining issue : figure out how to get it work when used through yabridge. What I noticed is that when I started BitWig while the standalone Analog Lab was running, the screen stopped working. (but the keyboard was still detected by Analog Lab).

[Bidinou]

OK. It seems to break Yabridge.

I tried to put the dll in the .wine/drive_c/windows/system32/ with the config file in ~/ then started bitwig. I got the popup indicating the rules were loaded. Then, Bitwig never managed to communicate with the VSTs.

I filed bugs reports here :
yabrdige + winmm_midi_rename : Plugin host does not respond · Issue #424 · robbert-vdh/yabridge · GitHub for Yabridge
and there :
winmm.dll replacement breaks Yabridge · Issue #7 · SanderVocke/winmm_midi_rename · GitHub for winmm_midi_rename

Cheers !

[Thorgal]

I know pretty much nothing about windows stuff (internals of a DLL, etc), but when I type file winmm.dll against the one from the midi_rename project and the one coming from Wine itself, I get a difference that may be of relevance:

winmm.dll: PE32+ executable (DLL) (GUI) x86-64, for MS Windows, 6 sections

winmm.dll: PE32+ executable (DLL) (console) x86-64, for MS Windows, 20 sections

Just a guess, but it could be the winmm.dll from the midi rename project is only overriding a few instructions from the whole instruction set of the default one (6 vs 20 sections). And maybe replacing the system32 one with a limited winmm.dll is not going to work as it is missing important sections. I could be completely off the mark though.

[Thorgal]

I just looked at the discussion thread in the winmm_midi_rename. It looks like kernel 6.15 will at least solve this issue thanks to Paul Davis who also got plagued by it:

https://lists.linaro.org/archives/list/linux-stable-mirror@lists.linaro.org/message/SXXKGOMLMGL6MMNBU4X43G67XUSIMV6F/

The discussion thread about Paul’s patch is actually interesting to read: Making sure you're not a bot!

[Bidinou]

Yep, that’s great news indeed ! That was a bit awkward to add a winmm.dll wrapper, that’s a surprising timing it gets fixed at the same time as my experiment

[Thorgal]

I patched the usb/midi.c kernel file with the kernel patch linked in the winmm_midi_rename thread. It works perfectly now

winmm_midi_rename + BitWig + Arturia KeyLab through Yabridge

[edd]

For the Keylab Essential it is a slightly different story:

They are all named: KL Essential 49 mk3 KL Essentia

→ Transparently queried the device #3 properties for interface query. Found device:
name: KL Essential 49 mk3 KL Essentia
man id: 255
prod id: 1
driver version: 1
→ No match, returning native result.

when winmm is used it is matched 4 times:

[Thorgal]

kernel 6.15 is out, I just checked the patch and the midi port name fix is in.

[Thorgal]

Kernel MIDI port name patch back-ported to kernel 6.14.9. I know that liquorix provides this kernel for debian based distributions as of this writing.

[soyer]

And it also got into 6.12.31.