Thank you very much, waiting for feedback when diving deeper into it!
I just tested it with a Keylab 88 Mk2. Awesome job, thank you very much !
2 Likes
Lucky owner!
Let me know of any problem you find or anything you find useful to add!
This script is top notch! The way you have multiple pages for all of the controls on the board is genius!
I haven’t had much time yet to see the scripts and how they work, but I’m curious…
Would it be possible to add the shift/ctrl/alt/fn bars to the Master fader/pot as well? I’d love to be able to hook that up to my main control room stuff. I.E. Hold shift pad, and the slider does control room monitors and the pot-encoder does head-phones. Personally, those are controls I reach for way more often than the actual Master fader.
Another thing I’m ‘curious’ about. The mkII has a dial for different DAWs (Hold the DAW button a few seconds and the option comes up to scroll through some choices).
Does your script use the Cubase setting, one of the others, or does it really matter where that dial falls when your script launches? I sometimes find it has moved itself to the Live setting…especially if I power it down and come back later (boot up the mkII and it’s back on Live).
Occasionally the mkII connection with the Cubase remote script gets borked if I try hopping between a user preset, Audio Lab, and back to the DAW mode. No big deal, as it’s only happened a couple of times and I have no idea why, or how to ‘reproduce it’. It might have been all my messing about with virtual ports to get this controller happy with multiple clients. I grab the controllers in a stand alone Bidule instance first, then pipe them on to whatever apps need it via loopMIDI virtual ports that are quite happy with multiple clients from there. Getting it all going again wasn’t difficult (save project and restart Cubase). So Bidule gets launches first as the PC boots, and combined with ASIO Link Pro, I can send any MIDI or Audio anywhere I want on the local machine, or via LAN/WAN with ease.
IO Config looks something like this:
KeyLab mkII 61 and MIDIIN2 (KeyLab 61) > Virtual Ports A and B.
I have Cubase and Dorico set to IGNORE these two mkII MIDIIN ports (and do the same for other MIDI controllers with USB MIDI drivers that can’t do multiple clients at once). This way I can run several different clients at once and still get a MIDI controller into all of them as needed.
mkII Outputs 1 & 2 I leave raw since Cubase is presently the only app I use that needs those so far. So your script connects directly to mkII inputs from Cubase.
Script Inputs
#1 B [MIDIIN2 (KeyLab mkII 61) > loopMIDI via Bidule]
#2 A [MIDI IN 1 (KeyLab mkII 61) > loopMIDI via Bidule]
#3 mk (loopMIDI)
#4 mk2 (loopMIDI)
Outputs
#1 MIDIOUT2 (KeyLab mkII 61)
#2 mk1 (loopMIDI)
#3 mk3 (loopMIDI)
The loopbacks (I’ve named mk - mk3) to the Mackie and Generic remote are in place as directed.
Yes, I took the latest MIDI drivers and firmware update from ACS/MCC before even trying to use it. I’ve tried using the MIDI Control app and swapping all the DAW options to Cubase and writing them back to the mkII (I assume the DAW option is a global setting, but repeated it anyway for all 10 of the user presets just in case). Maybe it doesn’t matter anyway and your script puts things where they need to be?
Hi Brian!
I’m using the Live control bindings in my script. That is, I’m using the midi CCs and notes sent by Keylab in this mode, and this has nothing to do with how we interpret these messages inside the scipt and handle Cubase. Even more, I’m sending back to Keylab mostly sysEx messages, in order to bypass completely its integration for any DAW.
In Live mode, we have a different way the pads react (they are constants inside DAW mode) and this is why I’ve chosen it.No worries, please leave it as it is 
Haven’t noticed something like this, maybe you’re getting back to a demanding page? For example, inserts with many slots filled up?
The way you described your ports’ setup, you should have the pair mk1 (out #2) and mk (in #3) in mcu and generic remote ports (mk1 as IN and mk as OUT). The mk3 (out #3) port is strictly used for sending out data to Cubase from the script when we have the corresponding setting on. Let me know if you need further details on this functionality.
In my implementation, DAW mode is not making any use of the user presets, since I liked to leave these presets free to the users, including myself
Sure! Note, however, that I never used the control room and since I’m actually thinking of adding a page just for it, I would happily hear any thoughts on how the script should deal with it.
Thank you for your time!
Can confirm this works with Nuendo 12!
Since they have the same code base I would be surprised if it didn’t but it was still nice to confirm.
Good stuff, thanks for making this available!
1 Like
Ah, then it’s normal to find my controller keeps popping back to that setting. Good to know
Several sessions later, and it hasn’t been a problem again. I probably had some things wired wrong. I had been messing around with various virtual port configurations in order to get all my controllers sorted, and available to multiple hosts. I think I’ve got it sorted now.
Personally, I’d be happy with shift/ctrl/alt/fn added to the Master Fader/Encoder/Button. Some good instructions on how to go into the script and point these where one might want them.
Personally, I’d probably put a control room control to my main monitors (volume) on the main fader. I’d have it so that is the default for the fader, and I’d need to shift to do the main mix fader.
I’d put my headphones (volume) on the Encoder knob (also as default position). For the button, I’d probably keep a ‘mute it all now’ as the default, and gradually add some things as needed, like toggling between mono/stereo, or maybe toggling the various monitors on/off.
The main reason I use the control room at all, is because I often do a lot of real time bouncing. I like to be able to turn the volume on the monitors up and down during the process without effecting what’s happening to the mix. Sometimes it’s even nice to mute it totally during a longer bounce (ears need a break, or need to communicate with someone nearby, etc).
I could be wrong, but a control room is something that every user might do very differently. Some (like mine) are quite simple and only deal with a pair of monitors and some headphones (through a field imaging plugin for headphone mixing), and others can get very complicated fast (multiple rooms, sending cues to different musicians, and so on). So I’m not sure the best approach to be honest. I think maybe a template page and documentation on how to change/add specific things might be the way to go?
1 Like
Good to know, and happy that it works for you too!
Thank you very much for the time to give your ideas on control room, really appreciate it!!!
Now, since I know almost nothing about it as I previously admitted, I guess I’ll just have to make the separate page for the control room, and let’s see how it goes from there
Unless a user really knows about scripting (at a basic level at least), I would hesitate to instruct what and where to change.
However, I can gladly create “options” in the mapOfGeneralSettings file, so that you can easily bind the master fader’s and knob’s states to whatever we need to. This is a preferred way, so that we don’t accidentally mess up with the script and at the same time keeping the core script “clean” I’ll let you know as soon as I upload the update for this.
Again, thank you very much for all the info!
Oh, by the way, the button under the master fader is not accessible unfortunately in DAW mode 
That works. Or even if there are pointers and variables of some sort that allow the user to use the graphical editor to bind stuff directly.
My last controller was an Akai MPK261. I really like it when it works, but after replacing the keybed for the 3rd time in 4 years (at over $200 a pop), I’m done with it! It never had a good ‘script’. I got pretty good at going in and binding stuff to Cubase parameters/options/commands, though I never had it shifting pages, doing controller feedback (light/unlight/color-shift pads/buttons) and such like your script does.
I only had to open the script itself one time, to force it to use some extra/different MIDI ports that weren’t possible through the Remote Control building UI.
I had it doing way more with the legacy ‘generic’ controller system. I’d been gradually fiddling with the ‘new’ remote system in anticipation of the dreaded day when ‘nothing I’d made before works anymore’.
Sadly, I still must roll back to some pretty old stuff to get a decent live performing setup. Cubase 12, HALion 7, etc…is just TOO slow and laggy. All of my live performing stuff relied heavily on those legacy remote controllers. I’d reroute a MIDI track through it with a virtual port to get at all kinds of stuff in the DAW that never got ‘control tracks’ of their own. Like launching macros, stopping the transport, and so on.
Cubase 11, with the dongle, and old versions of HALion…it’s a boss! A special controller track can even pop open a plugin UI for me as part of the sequence while I gig. Don’t work anymore since HALion 7/Sonic 7 take sometimes a full minute for their UI to open…ouch Still works for other plugins though (NO idea why HALion/Sonic take so long to open their UIs now). For Cubase 12, I’m slowly rethinking and reworking things. Maybe I can have the UIs open, and just push them in and out of the foreground somehow?
I guess that’s progress though. Once they get it working well again, it’ll be ‘obsoleted’ again. Back to page one! (or they’ll tell me to buy Live, abandon 2 decades of projects, and learn a whole new program…and spend 2 years ‘converting’ all my ‘obsolete work’ to the ‘new thing’?) laughing
You must have something weird going on there, as it opens straight away for me - you mean when it’s already got a pre-set loaded and you go back and open it again, right?
There is a “show/hide plugins” command within the “window” group that you can bind in the MR. (Keyboard shortcut too, obviously)
If you combine that with focus quick controls and the ‘next plugin window’ command you get a lot of control for live use very easily.
1 Like
Maybe. The day converted from dongle to dongle free it got bad
This happened first when taking Dorico 4. It bumped HSSE to a version that didn’t need the dongle.
Some time went by before Cubase 12 and HALion/Sonic 7 was out…Sonic and HALion were still snappy, while anything that used HSSE took AGES to open.
Moved to Cubase 12…same thing.
Sonic/HALion 7 came, and now those are slow to open as well. They play/sound fine, but the DAW stops scrolling, busy mouse cursor shows. Many seconds later, the UI finally pops up and things start moving again.
I’ll look into with new threads though. I don’t want to clutter this one with too much somewhat off-topic noise.
Thanks
True, and implemented in my script with Mixer and Channel settings as well
@Brian_Roland, I agree with @skijumptoes, seems very weird. I have pretty large projects running, Halions/Omnispheres/Falcons/NIs huge samples, Arturia’s emus, and the list goes on, at the same time. No problem with showing straight away. BUT, I have the sense that CB11 was more fast (?), stable (?). I really don’t know, that’s my sense while working with both.
Thanks for sharing this - it’s very disappointing that neither Arturia nor Steinberg have provided a functional script.
I am having a problem with your script though. Every time I run it (full or stripped down), the MIDI remote script console pops up with an error**: TypeError: cannot read property 0 of undefined (Line 7916)**. This line seems to deal with pad colours, and my untrained eye can’t see any problems like undefined variables in it. Any thoughts?
Hi there, this is a miss from me to note in the pdf guide. In order for this function to work as expected, your primary time display should be set to Bars+Beats:
Now, in case you don’t want this limitation, you can deactivate the “just-for-fun” lighting of the pads on beat change, by opening the mapOfGeneralSettings.js file and setting 0 to generalSettings.tapTempoPadLightingOnBeat variable. Save this file and restart the script.
Note that since Arturia has a DAW implementation based on MCU, they probably don’t feel the need to provide something more relative to the new midi remote by Steinberg.
However, rest assured that even if they do, most probably you won’t see more functionalities from the script I’ve uploaded here (and actually provided to Arturia too for reviewing/testing )
Huge thanks for sharing the script, Minas! It’s a fantastic bit of work and has made me feel much better about choosing the Arturia Keylab MIDI controller, as I questioned the decision once I realised there was no script available in Cubase out-of-the-box.
Even if there was a script with Cubase, I doubt it would have the functionality yours has.
@mchantzi A quick question, what is the best way of upgrading to the latest version of your script - remove and reinstall, or re-import the script over the previous version and check configuration PDF for any changes?
Thanks again, I shall look forward to future updates.
1 Like
Hi Phil, thank you for your kind words
I personally just re-import, I didn’t have a problem so far, Cubase warns us and then replaces the script.
HOWEVER, in case you have changed something in the other files, mapOfGeneralSettings.js, mapOfCommands.js and so on, and you (obviously) want to keep them, you have first to make a backup of these files, and after re-importing, replace them to the script’s folder.
In future updates, I will place at a new post here, just the core file of the script (whenever nothing else has changed), for users to avoid this. You can then, simply place it into the script’s folder (instead of re-importing) and just “refresh” the script from the midi-remote window.
2 Likes
Hey mchantzi,
let me start by saying thanks for the work, time and effort you are putting in to help complete strangers. Although I haven´t used your file myself, it always makes me happy to see that there are people out there just plain helping!
Having said that, maybe you (or other users of this forum that have experience with your script) can help me with a short question.
I want to buy a midicontroller and I am not entirely sure which one.
I want to use it with cubase 12 Artist. Furthermore, I want to run my arturia V collection as well as my pigment with it.
Most important thing for me is „ease of use“. In the past at times, I was spending most of my time trying to get my system to run properly and I just had it.
Due to the fact that I want to use the controller with the arturia V collection, I thought that getting an arturia keylab would be the best way to go. As I want at least some keys that would leave me with tree options in principle: Minilab, KeyLab essential and Keylab MK II. While I understand that there are HUGE differences between these options in general, for me the “ease of use part” is really important. As long as there is a significant problem there, I will rule out each and any product no matter what.
When I searched the internet, I found lots of complaints regarding the use of the MK2 with Cubase 12, almost nobody seemed satisfied. So, for me, I ruled out the MK2 model. But than I found your work and suddenly it seemes as if there might be a viable way to use the mk2 with ease.
That brings me to my question (sorry for taking so long ….):
Regarding just the midi-implementation and the aspect of “ease of use”: Which controller would you recommend? Minilab, KeyLab essential and Keylab MK II (using your script) or something completely different? Would you say that the Keylab MK II with your script can be used as good and easy as the essential with the file included in Cubase?
Thanks a lot in advance!
Yanus