Steinberg - MIDI Remote Editor roadmap? Critical issues and bugs

[Shor]

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:

MIDI Remote output rounding bug

MIDI sent out from Cubase for MIDI Remotes is seemingly sending a value*127.0 out to MIDI, which causes certain values that result certain values sending the incorrect MIDI value. See this example here where I print out the value of the control in Cubase from the debug console: Volume value in Cubase is 0.7637795… and this results in a value that’ll be cast to an integer when sending MIDI of 96 (96.99999999). Whereas this clearly should be sending the rounded value of 97 as in my example. [im…

MIDI Remote sending delayed (and incorrect) messages to my controllers

Hi, edit: This is in both Cubase Pro 12.0.30 as well as Cubase Elements 12.0.30 I’m working on setting up my midi controllers in Cubase right now, and wanted to make use of the built in GUI for making them, as opposed to scripting right now, as I’m just wanting to do some proof of concept while configuring things. I have a consistent issue with controllers sending back incorrect (and oddly delayed) midi to my controllers. Have a look at this data… in particular the last 3 rows here, as this …

MIDI Remote - Rubberbanding Issue

It’s my first time using the new MIDI remote after getting a Stream Deck Plus yesterday. Among many other things, I want to use the Stream Deck as a controller for Volume, Pregain and Sends for the selected track, but I’m running into an issue where small movements will immediately jump back to the previous value. Broader rotations work somehow, but are very janky and need 4-5x the rotation than should be necessary. I’ve attached a short video below. As you can see, moving the left knob by 1 cl…

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.

[m.c]

@Shor

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).

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.

[Nico5]

@m.c

in my script

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.

[Highly-Controversial]

@Nico5

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 .

[m.c]

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

[Nico5]

@m.c

Am I missing something here?

apparently yes

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).

[m.c]

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.

[Nico5]

@m.c

I’m not talking about the “new” midi remote api

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.

[steve]

@m.c

in my script I have

@m.c

I’m not talking about the “new” midi remote api

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

[Shor]

Yeah thanks for the replies above @m.c 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.

[m.c]

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

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

[Highly-Controversial]

@Shor

So I am hoping to either get attention and perhaps a reply from Steinberg about this actually being on the roadmap for the editor.

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

[Shor]

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.

[Highly-Controversial]

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

[mlib]

@m.c

Since in my own script I’ve totally neglected the direct midi feedback,

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

[m.c]

Hi @mlib,

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:
https://forums.steinberg.net/t/arturia-keylab-mk2-custom-midi-remote-script/841146/1

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

[Shor]

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

[Shor]

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.

[Highly-Controversial]

@Shor

Still being hopeful for some kind of response here.

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

[Nico5]

@Shor

Never send MIDI back to the same device that sent it

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.