Rumour has it that we are working on a new MIDI Remote API.
Usually we are not talking about our development roadmap, unreleased products or projects that are still under construction. But I guess we should make an exception from our policy here.
So, yes, we are working on a new MIDI Remote API that will allow deeper integration, a more convenient setup workflow for external MIDI controllers and more flexibility for manufactures to integrate their hardware. This is a huge project though and requires well-thought concepts and carefully designed UX. We are not there yet and hence we decided to invest further in this project.
This is what Cubase definitely needs. Any way to make connections easier, and making different hardware to integrate better with Cubase is a major selling point. Is it for hardware synthesizers as well or just midi controllers?
The most important feature that I really wanted from Cubase 11.
It’s good that you don’t release a half-a**sed version. I hope you really nail it when it gets released.
(a pro tip: look at how easy it is to setup Bitwig)
I appreciate that it’s a feature that adds value for the product so they wouldn’t release it early, but it’s also an example of something that could really benefit from a public beta - more so than many other additions. Mainly due to the many configurations and requirements that people have.
The big fear with any new feature is, once it’s in, there’s a reluctance to go back and improve on it no matter how significant a small change could make. I’d love to see Cubase reach out to it’s users and allow that feedback while it’s still in development, it could be enabled via a ‘beta’ option in the preference.
The added advantage is that the community could build mappings ready for when the feature is cleared for release. There’s a lot of people who would love to make this a better product, i’m sure.
Hi
Do we have to download all the content files. I’m updating a Cubase 10.5 installation, and there is a whole lot of content files in the download manager. Are they free additions or do we have to pay for each? Little info abot this, and the readme file is failing, so…?
Jon
To the Steinberg team: can we please have a two-way data stream in the API so that external devices can read data from Cubase and not only send control messages to Cubase (or have Cubase at least send data updates to the device when values change etc.).
More and more devices offer displays that need to have encoders and similar control displays updated with values in sync with what is shown in Cubase.
Eucon obviously works well for this, but that is a closed system.
@Matthias Quellmann
Thanks for the info! If by any chance some beta tester got thrown out for breaking that NDA, I would like to offer my services for that! Without bragging, I am probably one of the most fitting candidates to test new Cubase features, especially when it comes to a Midi Remote overhaul! I programm my own midi routing and automating processes in MAX and every year I get closer to my goal of being able to customizing my full composing template by touch screens and hardware controllers. But that is also the reason why I see very clearly what is not possible due to restrictions of the existing protocols like generic midi remote! Hence, I have a keen interest in being able to influence how the new approach unfolds. Needless to say, I would certainly never break an NDA! And did I mention I speak German?
By all means, please contact me, if you need further input and testing on this part of Cubase which is one of the most crucial ones to me …
The current Generic Remote Editor works in that way, you can set each hardware assignment to transmit or receive (Displayed in the ‘flags’ column). Been like it for years.
See ‘Flags’ section within the table at step 6 here:-
Yes, but this does not work for controlling plugin parameters when switching between plugins as you will loose the respectively set parameter value on the remote controller as soon as you bank to a different plugin / context.
So what is needed is an API call that can pull the current value for a parameter on demand so that you can init the controller values on the remote controller display when you switch to a different plugin / context.
Just like it works with Komplete Kontrol keyboards and switching between instances of Komplete Kontrol inside Cubase. All the encoder display values are set to the KK instance values when you switch instance.
Mackie protocol can also do some of that with banking. But far from perfect and super tedious.
Eucon is much better in this respect but that is a closed system.
As this new MIDI remote will be a replacement for elements such as the quick controls i’m 99.9% certain it will transmit and receive - track controls update and transmit as you change tracks already so the concept is the same, just when focusing on plugins and sub-pages of each.
With MIDI 2.0 we will hopefully see the next level whereby universal parameter names will be sent to hardware along with their values, so no more reliance on MCU/EUCON protocols to populate controller displays, really hopeful for that.
Is the idea here that the MIDI Remote enhancements will exist for manufacturers only, or are there end-user improvements planned as well? I have a ton of hardware controllers and I just want to be able to map them in Cubase on my own, then use those controllers to map to plugins/instruments/Cubase as desired, have those mappings recall, and just generally have things work. I don’t want to be limited to 8 Quick Controls or certain hardware. I just want it to work kind of like it does in Studio One. I map my hardware device, Cubase intercepts those controller messages, I assign those controller messages to plugins or the DAW, depending on Focus, Cubase retains the mapping and knows what to do next time I load the plugin. Bonus points if we can combine controllers.
If you’re building something with the expectation that manufacturer’s will plug into Cubase’s API, that almost sounds like you’re assuming they have a bunch of developers with a lot of free time just waiting for work to come in. If this is a system where end-users can map their own hardware and interface it with Cubase, then right on!
I should note: I do appreciate any company taking time to do things right versus doing things quickly and appreciate the update. This is a feature I’m very interested in.
Yup, that’s exactly what the API is i believe, i’d imagine it’s some kind of .xml file that we can edit/setup for hardware devices and it defines the hardware controls.
From that point, it’s within Cubase that you would map each parameter defined in the API to actual plugins. It’s possible of course that they may put some automapping concepts in there too to help with basic parameter mappings by default - using the same order as defined in the Remote Editor (i.e. used for MCU/Nuage maps).
Without bragging, I am probably one of the most fitting candidates to test new Cubase features, especially when it comes to a Midi Remote overhaul! I programm my own midi routing and automating processes in MAX and every year I get closer to my goal of being able to customizing my full composing template by touch screens and hardware controllers. But that is also the reason why I see very clearly what is not possible due to restrictions of the existing protocols like generic midi remote! Hence, I have a keen interest in being able to influence how the new approach unfolds. Needless to say, I would certainly never break an NDA! 
And did I mention I speak German? 
