Steinberg - MIDI Remote Editor roadmap? Critical issues and bugs

The new MIDI Remote Editor introduced a year ago is a huge improvement to creating your own custom setups with your midi controllers, and being able to create your own custom scripts is huge.

However there are still a number of huge, and in my opinion, critical issues that prevents many users from using it.
Is there a published roadmap where these issues are placed? It’s unfortunate that a few issues prevents many controllers from being used without making a custom script for them, when you have made such a nice to use editor for it in Cubase.

One issue is the MIDI feedback issues, where a sending controller is receiving the same MIDI that it is sending. A sending controller should only receive MIDI when Cubase, or another controller is changing the mapped parameter. This is how the old generic remote worked, and it’s a critical issue that needs to be fixed.
This can’t be solved by unticking the box to send MIDI back to the controller, as the controller still needs to have MIDI sent to it (encoders, motorized faders etc).
Coupled to this, we also have the behaviour where Cubase sends a delayed MIDI message back to the controllers that are mapped to a specific parameter/control, and this is often an outdated value, which causes really weird behaviours where it seems like a control jumps back.

Lastly, but possibly the biggest issue, is the fact where values from Cubase aren’t correctly rounded to an integer when sending back MIDI, which causes a lot of problems where some MIDI values may appear to get stuck if you make smaller increments. Simply casting to an integer will just cut off the decimals, and this needs to be a rounded value.

All of these issues are very well documented in a number of threads on these boards, including a few below:

Where are these issues on the MIDI Remote Editor roadmap?
They have not been referenced anywhere in any change logs over the past year of Cubase 12, and I would consider these critical bugs/issues.

I understand software development on this scale is very complex, but these are really critical issues, and they should be easily avoidable, in particular when the generic remote were void of these problems and bugs.


Not sure if this would be of any help, but in my script I have no “direct” MIDI back, i.e., I have not binded any of my controls to the midiOutput.

I’m using the exposed events by the API and then send proper messages to my controller to update whichever state is altered.

BUT I have no motorized faders to test if this approach would work as well, so probably your statement is correct, I just don’t know.

1 Like

many (most?) Cubase users don’t want to learn programming in an object oriented language environment just to make their motorized faders or endless encoders work.


100% spot on . people talk about ‘workflow’ and the biggest workflow killer is having your controllers broken and forced to learn how to script .


Most controllers already offer this basic stuff out of the box. Am I missing something here?

1 Like

apparently yes :slight_smile:

As per the OP and the prior threads referenced, the MIDI Remote is still not working properly with motorized faders (which are bi-directional and absolute CC pretty much by definition) and many bi-directional endless encoders in absolute CC mode – while just using the non-scripted user interface (which in many other ways is most excellent).

1 Like

My friend, perhaps I was misunderstood. I’m not talking about the “new” midi remote api, not even the “old” generic remote, but for previous existent implementations (mostly from what I see based on MCU). Again, I may be missing things, but talking for my personal setup (I have a keylab, a komplete kontrol and a panorama p), they all behave as they should, out of the context of the new api.
I’m not trying to change your mind, I ask mostly out of curiosity.

mmmhh — this thread is about the new MIDI Remote, so forgive me, if I assumed your post was related to the topic of this thread and my response to it.

If MCU works for your devices and workflow - great! Carry on and safely ignore threads and posts about the MIDI Remote.

If you’re asking why the MIDI Remote even exists, when MCU can do these things, that wasn’t obvious from your original response to my post - and it might be worth it’s own new thread.

The script you refer to @mchantzi, this isn’t a midi-remote script then?

1 Like

Yeah thanks for the replies above @mchantzi but I’m trying to focus attention on the issues related to the MIDI Remote Editor.
Like stated, programming your own controllers can work around many issues, but the whole point about this thread is being able to use the MIDI Remote Editor Steinberg added with Cubase 12, and I am a big fan of how it works as far as mapping and making your layouts.

However, the point of my thread was to highlight the critical problems it currently has, which means it unfortunately is useless for many controllers and users. I can program my own scripts, and I have, but I would love to be able to use the out of the box solution. So I am hoping to either get attention and perhaps a reply from Steinberg about this actually being on the roadmap for the editor.
If not, I just hope it helps bring attention to it so it does get put on the map.


Hi Steve, sure it is, based a 98% on the new midi remote api, and it works great (as far as I can test and tell)!

The reason I’ve entered this thread is to provide workarounds and nothing more. This is a habit of mine, not just in this forum (which is 99% musicians) but to other ones for devs.

Since in my own script I’ve totally neglected the direct midi feedback, I thought it might be of help for other users to know. And IF this workaround does not work, and since some things are really not there in the new API, then I had to suggest using previous stuff as well, cause to me, the important thing is to have something working, be it “new”,“old” or whatever. For example, in the API, I have no way of browsing through instrument plugins. No problem! I’ve just added a virtual MCU, connected its sysex to my own script and I was good to go. Or, since I couldn’t get the punch out state (this one is not exposed to MCU either), I added a tiny generic remote as well, again connected with my script. I’m more than sure, that in the future such things will be covered, I just can’t wait for an API to be perfect in any sense, I love to have my task done whatever it takes, and when updates take care of these missing or misbehaving functions, I’ll just update my script accordingly :slight_smile:

BUT, @Shor made this thread’s aim clear to me, so most probably my previous answers are out of context. All good :slight_smile:

1 Like

Never , this will never happen , we had to wait 3 months for a crucial midi note a line issue . Steinberg will never give you a time line . It’s just wait and see

I hear you, but I still want to try to get heard, as this is a huge problem since Cubase 12 and I am staying hopeful that it gets fixed.

Well , ive been waiting since 12.0.0 to be able to use all five of my controllers with rotary encoders .
There needs to be one hell of a MR update to fix these issues ,l as i say some of us have been waiting over a years


There are MIDI devices that does not use MCU and requires feedback to be of any use. A number of endless encoders for example.

Hi @mlindeb,

My script is not MCU based, it just uses a very limited set of its properties and in fact I have a stripped-down version which doesn’t use them at all. You may want to have a look here:

What I meant is that I’m not sending the messages directly, i.e. a mirror of the messages. I just wait for an event to be triggered (quite fast most of the times) and then prepare a midi message to send, making sure that the connected controller will understand it. Now, this is done via scripting, and as previously mentioned by other users here, this is not something that should be the default way to deal with this things.

Anyway, I quite get the purpose of this thread (took me a while, my bad) let’s say that my comments were of no use in this context :slight_smile:


Actually the update doesn’t need to be that big to fix these problems.
The underlying problems are these:

  • Never send MIDI back to the same device that sent it
  • Round values to the closest integer before sending MIDI

Still being hopeful for some kind of response here.
It really is a shame we don’t have a public roadmap for the plans ahead for these things. It’d be a real shame if this becomes part of the next paid update. What is even more a shame is that I’d probably pay for it, as I badly want this fixed.

You won’t get a response , when it comes to Steinberg it’s ‘tough love’ , it’ll happen when it happens , that’s the annoying part , that’s why i keep pressing , that’s why i make an idiot of myself because of the silent.
As i said this has been going on for a year with broken controllers

That’s actually not quite right.

If the controller sends relative CC, an answer by Cubase is needed to inform the sending controller what value to display.

For absolute CC messaging, there should not be an echo to the sending device.

1 Like