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.
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.
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.
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 !
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
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 ?
Because I like Linux, I can only agree, but I’m not in charge of roadmaps 
No, only SYSEX.
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 !
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 !
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.
Tadaaa, it works !
Tutorial :
{
"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
}
]
}
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.
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.
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).
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 !
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.
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:
The discussion thread about Paul’s patch is actually interesting to read: Making sure you're not a bot!
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
I patched the usb/midi.c kernel file with the kernel patch linked in the winmm_midi_rename thread. It works perfectly now
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:
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.
the keylab essential mk3 also works better now with the 6.12.32 kernel. winmm is not needed anymore
Follow us for the hottest sounds, fresh content, exclusive offers and Arturia news as it happens.
