Yep I agree entirely.
I posted a lot of ‘problems’ and such with the MIDI Remote API, but overall I have been able to solve all my problems using it, so that itself is a really huge positive for the Steinberg devs.
Things may not work the way they should yet, but they at least provided enough tools to work around the issues for now, so good job so far Steinberg. Just keep at it and listening to our feedback and we’ll have a great way to setup controllers, and hopefully the mapping assistant becomes a viable tool for this eventually as well.
1 Like
I think it’s quite a shame. Cool as the new MIDI Remote is, these are MIDI Controller basics. This needs to be addressed asap.
3 Likes
Yes - My M32 is SCREAMING to have it’s motorised faders all controlled by Cubase, but it just doesn’t work.
1 Like
Well it’s been a while - Still doesn’t work for my M32… Any success from anyone?
Thanks
There is an ongoing discussion concerning this issue, and I’m optimistic that it will be addressed.
I’m not sure, that the rounding issue is the same as the jittery motorized faders. Because the former is creating non-equal inputs and outputs, while the latter is introducing latency induced outdated outputs back to the input device (motorized fader pushback).
Both can cause jittery behaviour, but solving one of the root problems does not make the other go away.
1 Like
Hello my friend! I can’t be sure too, since I don’t have motorised faders to have a good look. So you mean that if you log the MR’s response to the controller it’s delayed? Could you please attach a screenshot with logging the responses? What I would like to see inside a mOnValueChange is:
console.log("Timestamp: "+new Date().getTime())
console.log("Value: "+value)
If you’re talking about the MR in the non-script side, surely it may be a quite different thing.
Now that I think about it, I do have a Nektar Panorama P6 with one motorised fader. I will try to see if I can control it, because Nektar has its own closed system to deal with Cubase. Anyway, I find the subject pretty interesting!
Yes indeed - I’m talking about the non-scripted way of using the MR. 
And to test it, I ran MidiOX between Cubase and my hardware controller (using loopMIDI), so I could monitor the exact time stamped midi traffic going back and forth.
I doesn’t technically need a motorized fader, because one can observe the problem also with an endless encoder in “absolute” mode, where the endless encoder internal value gets set by incoming traffic from Cubase. But it gets jittery when moving the hardware control a bit faster. e.g. I may have moved the hardware controller from CC value of 70 all the way to 75 by the time Cubase echoes the value of 71 (which the hardware has long since passed by). So the hardware controller now flips back to 71 after I had already moved it to 75. So I dutifully keep turning it, and the the overall result is jittery when observed on an automation track. Eventually I can get the MR to the right value, but not without a bunch of back and forth of values on the way from old value to new value.
If you move the hardware control very slowly, to compensate for the latency of the echo from Cubase, it works fine.
In my observation, the Generic Remote doesn’t suffer from this latency problem, since it doesn’t echo messages back to the sending controller.
Ah, cool, I can give this one a try!
1 Like
Ah great, now I see it!
Now, here’s the thing. I get TWO responses every time I send my CC. The first one comes with a delay anywhere between 25-50 ms. Not too much, NOT too small unfortunately. However, I find the second message more irritating and surely producing jitters. This one comes with a +500ms delay, which is surely unwanted. BUT, it’s this message that rounding MAY vanish. I can’t be sure, without seeing the mechanism of the MR unfortunately. But BOTH messages should be fixed, this I 100% agree with you.
1 Like
Are the two responses coming from the same MIDI input? Is there a chance you have Cubase AND your hardware connected to that Bome input?
If yes, one response might come from the MR and the other from your hardware echoing what it just received from the MR.
I had connected Cubase connected to MidiOx with two different loopMidi virtual cables, so the sending and receiving traffic would stay apart.
Nope.
Here’s a screenshot with two ports now, just to show that in my case it’s of no importance, since I’m using BMTs ports, not loopMIDI which can indeed can produce such things:
As you can see, I’m sending from port 1, receiving at port 2. IF port 1 for whatever reason would want to echo stuff, we would have another line in the logs. At the same time, the messages surely come from the MR and not from another Cubase’s function, since these ports are not assigned to any generic remotes or mcus and so on…
1 Like
So after a good night’s sleep I created another testing setup on my Win10 system - this entirely with the MR GUI - no scripting
hardware <==> MidiOx <==> loopMIDI <==> Cubase MR
MidiOx column heading IN means source port, and PORT means target port
I’ve labelled the ports in MidiOx
- hw means hardware controller
- MR means the Cubase MIDI Remote
I can see occasional “double” or even triple entries from the MR to the hardware. However I think these are just the MR catching up. For example, here’s one little sequence when I move the hardware just very quickly by a very small amount
I’ve added my (possible erroneous) interpretation guess to each line
572698 hw MR 191 7 56 # hardware sends value 56
572737 MR hw 191 7 55 # MR returns value 55 (maybe the rounding problem?)
572783 hw MR 191 7 56 # hardware sends 56 (**again**, because the prior message had set the hw back to 55
572805 hw MR 191 7 57 # hw is moving quickly so is sending 57, 58, 59, without any response by the MR
572815 hw MR 191 7 58
572836 hw MR 191 7 59
572848 MR hw 191 7 59 # finally, after some delay, the MR responds with the last value - this one is actually good!
572862 MR hw 191 7 58 # WTF? now we're going back? is this out of sequence? Or unpredictable rounding?
572943 hw MR 191 7 59 # hw sends 59 again (since the MR set it back to 58)
573506 MR hw 191 7 58 # WTF again!! we're getting a 58 rather than a 59
So the hardware seems to act predictably, but the MR not so much.
1 Like
Exactly. We’re seeing response delays. The reason that sometimes you see the correct value coming before the outdated ones is that all these are happening asynchronously. This is not bad at all, on the contrary, async is the way to go to not block our threads. As to why such big delays occur, as you can understand I don’t have an answer, but surely @Jochen_Trappe will have a clue and solve it without me knowing the timeline, since I know nothing about his scheduled tasks
ok - I totally understand the merits of using async communications
But not solving this issue makes the MR GUI effectively unusable for motorized faders and some otherwise very good hardware like the endless encoders on controllers from NI. So I hope this will be a priority.
1 Like
I agree my friend.
Ah, so you’re not using my script for the Komplete Kontrol, got ya 
I have to admit, I’m not using my Komplete Kontrol Mk2 for this purpose 
, because it’s in a drawer under my desk, usually only pulled out when I’m actually playing or recording something from the keyboard.
I have a Maschine Mk3, a Machine Jam and a Traktor Kontrol X1 on my desk - and those are always within easy reach, so they are really my main MR / Generic Remote controllers. 
1 Like
WOW, cool setup mate!
I always like such setups, and make me having second thought about the minimalistic approach I take, i.e. use just one midi keyboard for everything. But then again, I do have 3 midi keyboard active now, so, yeah, whatever
1 Like
So, despite the possibility of asking stupid questions now, I still want to get a clearer picture of the problem.
All MIDI Controllers I know update their current value / value indicator internally. So If you send MIDI data to the DAW, the MIDI controller will update accordingly, without the DAW needing to send data back, right? So the reason for sending MIDI back to the controller is so that the DAW can report changes in parameter status that’s NOT actually coming from the Controller itself. So… wouldn’t it just be enough for Cubase’s MR to not echo MIDI to the Controller (i.e. MIDI Port) if the parameter changes come from said Controller itself?
Currently, turning off “Send back to Hardware” disables MIDI Feedback for value changes entirely, which I don’t quite understand.
Sure. This is actually a good solution to this issue, when using the mapping assistant, while if using scripting, this can be solved by code.
The thing is that “binding” is expected to do exactly this: Send feedback to the controller, whichever object performed the trigger, be it another controller, the UI or (as already noted, unfortunately) the controller itself.
Currently, I’m not even sure that the problem is caused by the almost immediate feedback (below 40ms) to the controller, or the quite delayed one (approx. 500 ms after the trigger). But, anyway, let’s wait and see what a future update may bring on issues like this one