I would like to know too
will mackie be once also integreated there? And will there be an option to divide incomming midi from the midi cubase is sending back, for example i use relative 14 bit mode to send it to cubase but the controller needs absolut data to set leds or faders or whatever according to the real value set in cubase.
Uwe
P.S. and the faders or knobs are jumpy if i use my maschine or whatever as midi controller, this is also a problem of the midi sended back to the midi controller i guess, but this is not new, the only controller i know where it worked really good with some knowlege was the bcr200 and bcf 2000 but this was because of the capabillities of this controller with BCEdit
I’m not going to bother with this for my Oxygen Pro 49.
There is a mode button that changes the function of the buttons under the faders (Record, Select, Mute, Solo or MIDI (Device Function)). Even if I were able to map this all, it would be a royal PITA to set it up. It’s actually far easier to map this for Cubase using Mackie Control and the M-Audio Preset Editor.
I did test with a script for the Faders and Knobs and Inconsistent Pick-up behavior in Cubase 12 still renders them unusable, even though they pick-up properly in Studio One 5 - so, it’s definitely a Cubase issue, not a FW/Hardware issue.
I’ve never been able to get pick-up mode to function consistently in Cubase (10.5, 11 or 12), and I think I’ve given up 
I want to replace this controller with a Keystation MK3 of GX49 to recover a bit of space.
EDIT: Also, since the Cubase 12 update, I can no longer Bank </> with my controller, so the faders and knobs are officially dead.
Does Steinberg plan to support KeyLab MKII? They’ve already got KeyLab Essentials and MiniLab presets, but nothing for KeyLab proper.
Maschine in MIDI mode? Should work. I don’t see why not. I use it as a MIDI controller sometimes, usually with Ableton though, but as long as it’s set up properly as a MIDI input device it should work.
1 Like
Keylan MKii already works with cubase 12 they have the directions on there site… mines works fine…
1 Like
NI S61 original.
Anyone tried to map that?
All I can get to respond are the 8 rotary encoders.
Had a similar issue with an AKAI MPKmini original. The rotary knobs would not work. Only pads and keys.
The interface seems to like to re-size itself as well. Placement of knobs and buttons is funky.
Hi Jochen,
where should we have discussions like this? A subcategory at the developer section?
This code snipped is great and pointed me into the right direction.
When I implemented my script for the CC121 (see in the CC121 forum), I noticed a few things, which I add here. And yes this is probably far off the sweet spot as well…
I would love to have the inserts supported. So I could support the fabfilter Q3 from the CC121 natively…with access like:
hostSelectedTrackChannel.mInserts.getByName(‘Pro-Q 3’).getPluginParameter(‘Band 1 Frequency’)
or via getByIndex, but then I need to get the name of the insert of the specific slot. And a function to open it’s UI. I would also like to have routing info to switch from a channel to the send’s track or to open it’s UI.
I missed to read properties e.g. to check if a track is armed or to get the name of the current track, etc. All the parameters are there, but I didn’t find out how to get the actual value, except by hooking in the change event. This is needed to create more dynamic/complex scripts.
The documentation is not very clear. E.g. how do you support parameter lists properly? E.g. the filter type has 9 different parameters. With the CC121, I would like to step through it by each increment of the knob. I tried with mapToValueRange without success.
I also encountered a bug in the Remote API. Do I send this to support only?
However, I like the integration in Cubase with the ScriptConsole and the log messages. And also the completion in Visual Studio Code is a great support tool and time saver. I know, this is the start…
1 Like
I would love to have the inserts supported. So I could support the fabfilter Q3 from the CC121 natively…with access like:
hostSelectedTrackChannel.mInserts.getByName(‘Pro-Q 3’).getPluginParameter(‘Band 1 Frequency’)
or via getByIndex, but then I need to get the name of the insert of the specific slot. And a function to open it’s UI. I would also like to have routing info to switch from a channel to the send’s track or to open it’s UI.
Yup, this is in the direction I want to see for inserts!
1 Like
Today i could update to Cubase 12 and test the Midi Remote and i am excited, nearly impressed. Even if it is very basic currently (v1.0), it does go into the right direction. Sadly i can not handle the API stuff. This is beyond my skill, but there will be people that will do magic things with it. From the looks (on the API code), you have nearly everything what the Cubase DAW has to offer.
The new endless rotary encoder options are great (sad, it took years to have them). They work on my Mackie C4. I used the “Relative Signed Bit” method and now they are working properly for the first time and i can use them at least for something. Even 14bit resolution is possible, which is realy great for the finer tunings (like EQ, Volume etc.).
While the Midi remote editor is very easy to use, it comes with the downside that it is not flexible if you want to add functionality that the editor does not offer. For such stuff, you need to open your script with a text editor and try things from there (i.e. add stuff from the API code).
What i am really missing, is the bi-directional feedback stuff, like encoders with LED rings (for the feedback). I agree with Uwe449c on this point. People with high quality encoders (that offer LED rings), can not use their full potential. What i do not understand here is, why we need to setup Midi Out AND Midi In, if there is not a single option what to do with the midi data, that is send back from the Cubase DAW.
Personally, i am sad that i am not able to use the knowledge of my own controller. I know my Mackie C4 inside out. Outside Cubase, i can write things for every knob, button, display literally every aspect of the controller. I know the midi commands, sysex that it needs, but i can not use this knowledge with the midi remote editor or the open API code, because it works differently and you need to understand that code. This annoys me the most. I am very, very sure that if i would work with a person that understand this API code, i could write a full working script for this controller easily in 1-2 days.
@ Jochen_Trappe :
So this is what i offer: i pay two work-days for one of your experienced workers to write together, a full working script for the Mackie C4. I live in Hamburg, so this is really possible to do. If there is a interest, you can PM me.
2 Likes
not really good, i prefer to use my maschine studio still as mackie control with my own mapping, if i use the cubase midi mapper it all behaves strange, the knobs jump a bit around, but this issue is not new and existed also before, or you use all just in absolute mode with pickup function - but that is sooo last century in oppinion
Uwe
Hi @MarcoE ,
Thank you for deep diving into the API without any fear. 
You’ve already reached a topic that shook our heads a lot when designing the API. How to stay “generic” but access custom project setups using 3rd-party plugin etc as well. For now we decided to stick with the Quick Controls as the decoupling layer of choice.
Maybe by having a (solution oriented) discussion about it, we’ll find the right way to stay “generic” and access individual plugin-setups as well.
And could you please explain what bug you encountered in the API?
Thanks!
3 Likes
@Jochen_Trappe How do we obtain a list of available states that can be pulled from the plugin/devices? i.e. I see this in the Arturia scripts:-
activeDevice.getState(‘TrackTitle’)
But I can find no documentation of the available states that we can pull. Is this part of the VST3 spec and documentation can be found there?
Thanks
Hi @skijumptoes,
the setState/getState is not accessing Cubase functions. It’s for script-internal state management. the “activeDevice” represents the detected/activated MIDI controller. It should be avoided to use getState/setState, as state-management is always a difficult thing and creating unexpected/undesired behaviour is very likely to happen then . Only if things get too difficult when updating hardware displays/leds etc, it sometimes is useful as a fallback.
On the Arturia-keyboard the problem was that the text display is driven by one single sysex-message. We wanted to show different infos there, so the script needed to “remember” the states that came in via the callbacks.
At the moment the way to read track names, colors etc is by using the callbacks mOnTitleChange etc on the API’s HostValues.
2 Likes
Speaking of which, might this be a start for a future evolution of other areas of Cubase being more scriptable?
This seems to be a JavaScript engine inside Cubase. Wouldn’t it be great to have this leveraged to do what PLE is doing now?
On a different note (I asked this in another thread as well), is there a particular reason for choosing JavaScript instead of Lua for this API?
1 Like
The MIDI Remote API has a specific purpose:
It is an abstraction layer between the midi hardware and Cubase. Of cause it is a very reasonable thought to open that to use it as a script-base PLE, but that is not the purpose of this specific API.
The reason why we chose JavaScript over LUA is because of the language’s popularity and the auto-completion capabilities in Visual Studio Code.
3 Likes
I understand that, but I was talking about future developments. The directions where this should go seem obvious to me 
Is VSC mandatory for dealing with this API? (I like a lot of things about VSC but hate its footprint and slowness).
Interesting reason re: Lua, considering that Lua is kind of an “industry standard” scripting language in the audio and music world. Moreover, people doing GUI design in this industry should be versed in Lua, as is the language for HALion, Falcon, Kontakt etc.
VSC is not mandatory, and I understand your concerns regarding its footprint.
Does the word “industry standard” really apply to remote script integration in DAWs? Ableton, Bitwig and others use Python, JavaScript and even plain Java.
I think LUA is a great choice when performance is an issue. But as the MIDI Remote API is more declarative, we decided that JavaScript covers our needs very well.
3 Likes
While i understand why you use a script language, i still do not understand how that will help “normal” users. Lets say i have the full midi implementation of a hardware midi controller, how can i use this with the script language?
For example, i know that my encoder transmits with CC0, but the LED rings on that encoder receive on CC32. I am not able to use that with the midi remote editor or with the API script language.