Arturia Keylab MK2 Custom Midi Remote Script ( MKII )

Thank you very much for fast help! Changing code helped a little bit, but I recognised that the problem was in the colors I used. When I changed hue a little bit, colors were changing dramatically so now I use only colors that Arturia can proceed and which are working.

Thank you both once again for responding:)

1 Like

Ah, maybe this is why I hadn’t noticed something, I always use some defaults. Good to know!

I am using Cubase 32-color palette and as said before I have a macro which sets the tracks with these colors (in a different order so that successive tracks use quite different colors). The colors on the Keylab’s buttons are REALLY close to those colors. Didn’t have to tune the hue…

On the topic regarding track colors, I made a short tuto video yesterday that shows the way I created the track colors so that they look good on my Keylab using m.c.'s scripts.

1 Like

Cool! I’m curious, do we need your tuning part for the colors or the script will show them as expected without it? Currently I don’t have my Keylab enabled to check.

By the way, I do use PLEs for coloring tracks too, though I prefer to assign colors based on the track names. It’s just an addition to the PLEs I have shared with the script for track naming.

Yes. To be more accurate for the colors I use the corrections

Hi! Just found this script and fantastic work!

Has anyone tried using winRT midi and this script? I can’t get it to work. Maybe it’s the settings of the Arturia MK2 that is the problem but my status is consistently “disconnected” when using WinRT. Tried changing the expected ports in the script without success. Cubase is showing a KeyLab MK2 and DAW midi in port.

I use WinRT since it solved some freezing problems I had. Without winRT the script works just fine :thinking:

Windows 11
Arturia MK2 61

Hi Pettor, my answer most probably won’t be of use, but the whole subject is interesting to me.

Under WinRT, Windows sets the keybed midi output port of our Keylab friendly name to “Midi”. I’m not even sure if WinRT is to blame here, or Arturia.

Now, Cubase, for reasons again I don’t know, instead of bringing this friendly name (friendly name is actually how it’s set in windows registry) doubles the daw port friendly name, so now we have two “DAW” midi output ports.

My script is searching for ports (input and output) with names containing “DAW” and since in the midi outputs there are actually two of them, the midi remote API cannot differentiate and the automatic recognition of ports is aborted.

Furthermore, if you try to setup the controller ports manually (outside of the script) you will see just one midi output entry “DAW”. This is unfortunate, because even if you choose it, Cubase midi will run into conflicts, and I never show it working as expected.

There is a small “hack” we can do, to prevent this nasty issue, but it’s not something I would advice anyone to do, I’ve tried it and it works in Cubase 12 but NOT in Cubase 13 (0.40).
The idea is to find the friendly name of the keybed midi output port key in the registry of Windows, and instead of “MIDI”, set it to something more meaningful, for example “Keylab Port 1”.
I can provide more info on how exactly to do this, but the thing is that upon every system restart or even when we turn our Keylab On/Off, this friendly name will return to “Midi”. This means, that each time we have to edit this registry key. One can have an external script performing this operation. But when we think about it, is it really worth it?

I personally never used my Keylab in WinRT, but at the same time, I never turn on/off my controllers while working in the DAW. So I never had real issues with disconnections, well known in this forum, and as far as I can tell in the 0.40 version there has been an attempt to fix this without WinRT.

If you ask me, I think that the future is with WinRT but it still needs work and in the mean time, I’m just avoiding it.

Thank you for the reply!

Great explanation and I can verify made it work for me by simply deactivating (having ‘active’ unchecked in midi settings) the DAW out midi ports for now. This will disable some nice functionality of course but I mostly use the keyboard for the inputs.

The registry hack is smart. I changed registry a lot on Windows for other things and there are ways to overwrite a key on startup. Maybe that would be a valid way to fix it actually. Where is the registry key located?

Over the years with Windows, I’ve run into an assortment of MIDI driver issues. One way I’ve always been able to get around them with consistency is to first have something like Bidule or Bome grab problem devices/drivers, and then divert streams into virtual ports (such as loopMIDI).

I’ll do this BEFORE launching Cubase/Dorico/Etc. If the device properly supports multiple clients, I’ll even blacklist MIDI controllers if possible in everything but Bidule/Bome and rely on the virtual ports to get MIDI streams into and out of whatever apps I like.

I find this approach grants a lot of advanced flexibility too. Real time transformations/corrections, echoing data, splitting MIDI streams, and more.

1 Like

You can find the entry here:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceClasses{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814}##?#SWD#MMDEVAPI#MIDII_DC1DBBFC.P_0000#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814}#\Device Parameters

This one is for the midi out of our keybed (NOT the DAW which is OK).
You’ll see the key FriendlyName which is set to MIDI.

Change this with something more meaningful, for example, say, Keylab Port 1.

If you now open Cubase you will see the new name:

Normally, the script will recognize the ports properly and you’re good to go, at least in CB12. In CB13 I saw some issues.

However, as already said, upon a PC restart, a device reactivation, updates, whatever, you’ll really have to redo the above.

Is it worth it? Honestly I think no. @Brian_Roland 's suggestion makes much more sense to me.

1 Like