So, since it’s been 1.5 years since CB12 and MR, Steinberg is either ignorant and doesn’t care, or programmed MR with a fundamental flaw? If they can’t tell whether the Par change came from MIDI (and which Port) or from the DAW, what are they going to do about it?
Even if they remove the late echo, I can guarantee you I can turn my knob fast enough so it’s going to be a problem. Especially on fast accelerated ones (e.g. ACC3 on Faderfox)
If you mean whether the MR knows where the change comes from, rest assured that it does.
The way I see it, if they remove the double feedback AND bring the first one at a pretty small latency (for example in scripts this latency is 0ms) say 1-2 ms, the issue will be resolved. HOWEVER, at the same time, they can change the “Transmit to Hardware” checkBox to a comboBox or choiceBox, containing “Transmit ALL”, “Transmit non-echo”,“Don’t Transmit” or something like this.
Even if this is the case, I cannot imagine having to build everything from scratch, it will be a pretty limited area to work on. But yeah, without seeing the code, one can never be certain of anything,
2 Likes
The fact that Steinberg hasn’t addressed this yet is irritating to me, even more so if it’s not a more deeply rooted problem in the MR. I mean, how many people are using NI Keyboards or any other controller with endless encoders? This must have come up in their support inbox over the past 1.5 years…
1 Like
Do you have an MK2? Out of curiosity, tried my script?
1 Like
Not yet, but I’m checking it out right now. Thank you!
1 Like
Unfortunately the ‘moving it slowly’ technique you describe will not work with a real motorised fader, as the fader fights to reposition it 'self and moves of it’s own accord.
I hope they fix it one day as controlling the mixing desk during mixdown was the main reason I upgraded to Cubase 12. After all this time however, I’m not confident it’s a priority for Cubase the product owner.
Thanks
Pauly
I fully agree for real world usage - and if you were aware of my posting history on this subject, it would probably be more obvious that I don’t think “moving controls slowly” is a sensible work-around.
This needs to be fixed at Cubase level.
1 Like
I’ve tackled a lot of these issues myself - my insight:
The double midi echo is, well, two things:
- Immeidate feedback of the midi signal recieved;
- A cubase code that does a “send state” type of message around… can’t remember… 300ms after anything is touched. Intent would be to update a controller state outright to ensure things are in sync.
The feedback/echo is a pain though. Similar to someone else in this thread, I solved it a while back using code (in BOME for me) to open a “window” so that cubase send messages would be ignored. It works fine for motorised non-latch contorllers… but is IS a work around. For me, my window needed to block the initial feedback / echo (“1” in above) but let through the second one (“2” in above)… otherwise it wouldn’t update settings on e.g. project open (the second message, again, is some kind of :“update state”… I don’t have it all open in front of me, but I remember it possibly even sending ALL mapped messages at that moment?).
So - workaround… works… kinda.
What would be important though, is that the initial cubase code is revisisted. Having an instant mirror echo should be easy’ish to solve. Either timestamp incoming singals and filter specifically; or use a tiny window like I’ve already been able to to do… in combo with “which port did the message come from; which port is the controller again??” logic in cubase, this should be easy to code out. The second one needs a rethink… The “update state” is important… but sending potentially hundreds of controller data states to a controller that probabably sent the change in the first place seems… a bit OTT. I think it would be ideal for cubase to know specifically which port / channels are assigned to a controller and just assume that if a change came from it, then it doesn’t need a full update. Even might be useful to have an “update state” button / function and typically leave this function out of it all together. Not sure…like I said, this second one is a little deeper / trickier…
Oh - and yes, that “update state” function does screw things up… moving a mortorised fader slowly will sometimes lead to it recieving that “update state” message, and give sudden feedback in an “I’m breaking your motorised fader” kind of way (particularly common if sending a CC value from a fader that has NRPN accuracy… I think it’s the mid-way values that freak it out)…
NOT FIXED IN CUBASE 13 PRO - what a drag.
4 Likes
I’ve only just started using Cubase 13 and the MIDI Remote and am encountering this problem. Strangely, to me, some synths/brands seem fine while others are very bad (Cherry Audio and Arturia seemingly the worst).
It’s an (another) annoying issue I hope Steinberg fixes.
1 Like
Someone suggested I contact Midas and I did, after a few back and forth emails, they told me to try contacting Steinberg, which appears a near impossible task. I have messaged the local distributor. Lets see if something happens.