I just tested this in the 12.0.10 update (on Win10), but I don’t think it delivered the right solution for
motorized faders and
endless encoders that track current position in the hardware
When disabling the midi feedback to the hardware, the MIDI Remote now seems to stop sending midi messages, even when the change to the Quick Control is originating from Cubase (or from another control surface).
I think the MIDI Remote needs to work like the Generic Remote:
The Generic Remote sends messages to the hardware, when the change in value
originates from Cubase
via moving a control in the GUI, or
originates from a different hardware device
But the Generic Remote does not echo messages back to the same hardware device that sent them.
So the new MIDI Remote is still not very useful for
motorized faders and
endless encoders that track current position
and I will need to continue to use the Generic Remote with such controls.
Just tested it in C12.0.10, “pickup” mode is now much better than before and it’s now the smoothest among the 3 takeover options. However, I’m not tested for a midi controller. I’ve one but no time to test it out yet. And my midi controller seems does not have endless encoders. However, it’s still when opening the dialog, or using C11’s generic remote will have smoother result. Does the echo issue still happening? “Jump” and “scale” mode basically behave the same as in C12.0.0
OH… I just figured out I can turn off transmit to hardware in the surface designer on the controls’ properties. Now everything is very smooth with all the take cover mode for my use case. I do not have endless encoder or motorized fader so I do not know the other issues remain.
It’ real nice update Steinberg ! You added some new feature but it is UNUSABLE, or usable in limited way what we don’t want.
Again and again you customer are regular beta testers who pay you for it… nonsense.
I would like to use new MIDI mapping , do something with it !
So, are the wizards at Steinberg working this issue? When I saw every channel of my m32 could remote Cubase channels I was stoked! Very disappointed it doesn’t work, so hoping there is a solution coming.
It would be nice if all modes had a method or parameter to tell Cubase whether or not to send MIDI back to the device. It would also be nice if there were a callback to the script that would provide the normalized value from Cubase… that didn’t cause latency issues. I.E. let the script writer control the feedback to the device.
Very well said. I just recently upgraded to C12 and I was excited about the new remote control options, but the way parameter feedback got changed totally ruins it. I’m only using control surfaces with LED rings and endless encoders so I do need parameter feedback but currently that’s useless.
I monitored the MIDI activity between Cubase and my controller, and came to the same conclusion as written above. With the old “generic remote” I only got parameter feedback when the change was done outside my controller (either originating in Cubase or another controller). There was no MIDI sent to my device when I used it to control parameters.
The way I see it, this should be a relatively easy fix (especially as it’s been already implemented by Steinberg ages ago), I would really appreciate it if this was addressed in the next maintenance update as otherwise the new editor is really cool.
Looks like there is a workaround, I found this when playing with Giampaolo Gesuale’s excellent BCR2000 template.
Using Relative mode for the MIDI CC control does resolve this issue.
Cubase is set to relative (two’s complement).
BCR2000 is set to REL1 mode.
I’m not sure if this would work with any controller as not all of them are as flexible as the BCR. So the ability to use the absolute mode as we did with the Generic Remote would still be great - but this solution works with my setup.
That’s interesting and might be useful for some situations.
I’ve been hesitant to use relative, because in at least some cases, relative makes the target parameter change in very tiny steps, rather than in a sensible scale.
It was quite a while ago, when I last tried it, but I remember it was some sort of frequency cut-off or EQ that would change by 1 Hz for each relative change. And obviously that’s rather useless when trying to change cutoff frequency from 1000 Hz to 2000 Hz.
This will depend on the controller. On my icon Platform M+ relative mode (two’s complement) is used but the relative value sent increase with the velocity with which it is turning - slow being one, fast being something larger (can’t recall, but fast enough to zip around an EQ Frequency change without any bother).
Are you using Relative Mode bi-directionally? i.e. if you turn a connected control in the Cubase GUI, does it update the value reflected by the LED rings in the BCR correctly?
What about when you change tracks or plugins? - Do the LED rings reflect the settings for the newly connected Cubase controls correctly right away?
I’ve been able to make relative mode work in unidirectional connections - i.e. from controller to Cubase, but not in bi-directional connections.
Also: I don’t see how relative mode would make sense for motorized faders, since they are inherently in some absolute physical position. So the jitter problem needs to be solved as I suggested in a prior post, by not echoing midi messages back to the sending controller, but only to all of the other one’s. And of course it needs to send Cubase initiated messages to all connected controllers.
That’s how the Generic Remote works perfectly well – with endless encoders as well as with motorized faders.
So my disappointment about the MIDI Remote not doing it that way is still unresolved - and for now I find myself using the Generic Remote for those bi-directional situations even at 12.0.40, while the jitter problem was identified as an issue already in 12.0.0
If yes, does the controller reflect the correct values of the Cubase parameters currently connected? Even right after changing presets, channels or plugins?
I’ve only been able to make relative mode work correctly in uni-directional connections. i.e. hardware controller sends, but doesn’t receive (or doesn’t react to received data for endless controllers).
I can’t recall if you were involved in my other thread where I talked about the midi rounding bug, but that was at least confirmed by Jochen and I hope they fix that soon.
Through my research I verified that the rounding is part of the jitter, and I did solve that in my own scripts. I also did a hack to get around midi feedback as well, and I think I have my code shared for that somewhere here… basically in short I create a visual controller representing the fader/encoder in Cubase, as well as one control that is connected to the ‘real’ hw controller.
In the handler I keep track of the last sent value from hw, and if that value isn’t changed, it’s not sent back… i.e. it now works the way we want. If cubase or another controller changes the mapped parameter, it is sent to the hw… if the hw itself changes the same parameter it is not echoed back to itself.
It works great for me, for absolute controls. For relative it doesn’t work as neatly (but decently).
I wasn’t involved, but I did follow with interest!
I’ve described the problem in detail earlier in this thread but the TLDR is, that the echo for a controller value appears at the sending device AFTER the hardware controller has already moved on to one or more new values. And because of the late arrival of the echo, the echoed value sets the sending controller back to an older value. Producing jitter in endless encoders and push-back in motorized faders. I believe there’s at least one separate thread about the manifestation of this problem with motorized faders.
I’m not sure your logic would work in the test case I described, because the hardware controller may have already sent a second or third additional different value to your script before the echo from the first message shows up in your script. In that case your logic would not recognize, that it’s an echoed message and send the latency delayed echo and therefore the jitter.
In your script logic, you might be able to solve for the most common use cases by keeping track of all incoming messages during the last X milliseconds ( with X > round-trip latency )?
Side note: I’m using several hardware controllers simultaneously, which may cause additional latency. So, if you’re only using one hardware controller, and/or a faster system than mine, you may not experience as much latency. I haven’t thought about it much, but either the latency compensation in a good script might have to be rather pessimistic, or there would have to be some sort of latency detection logic for the script to be seamlessly transportable across many different environments.
So I still believe, the only reliably correct solution is for Cubase to NOT echo back to the sending controller script, because it’s only deep in the bowels where all the scripts and Cubase internally get coordinated, there’s enough reliable information to stop the echo.
Actually you are right, and I kind of forgot about that late message (which I also cleaned out).
What I observed from a controller was actually this:
Controller sends midi cc
Cubase echoes midi cc back to controller (but without rounding, just chopping off decimals, causing rounding errors)
If the last message your controller was sent was longer than x ms (can’t recall exactly, there’s some throttling algorithm in Cubase that monitors this), then it sends ANOTHER echo about 300ms later with the same rounding.
This is the combination causing all of this mess, and it gets worse the more controllers you have controlling the same thing.
So in my script (yes unfortunately midi assistant is entirely useless for this for now, and requires scripting to make it okay to use), I always keep track of the very last message sent my the control, and if cubase echoes the same message back, I simply ignore it. This ensures that I never echo a message back, and it also means I never send the delayed echo either.
So absolutely nothing gets echoed back to the controller sending out midi for me.
I did actually streamline it so much that I just have a single function to create my controls now, to ensure it’s not a huge pain to setup.
Yep 100%. Unfortunately mapping assistant is too buggy and not working good enough for anything that needs to receive midi back, and I really hope we get a fix for this soon, even if I am admittedly not super optimistic.
A device sending midi should never ever get that echoed back to itself, and midi must be rounded, and not just have decimals chopped off like Cubase is doing right now.
It’s not a hard problem to solve programming wise, but it has to be done, and I feel like I had to fight a very long time to just get any of this acknowledged as a real problem. Both midi rounding and the weird delayed midi feedback. The later is still not something I got a confirmation from Steinberg about, even after I tested it myself on different computers and controllers…but it’s clear as day to me, in particular after I fixed it myself in my scripts.
I really do hope Steinberg can actually confirm these specific points about what is causing the problems, because I am 100% certain these above issues is the problem, as those are what I attacked and solved in my scripts.
It does work as expected. Controller updates when you make changes within Cubase or when you change tracks.
Both Cubase and the controller need to be set to relative - I’ve got a BCR2000, not sure if this will work with all encoder based controllers, but it does work with the BCR.
As written above, Cubase is in two’s complement mode, BCR is in REL1.
Obviously the way the Generic Remote was implemented is more versatile and it will probably work with any controller.
Have a look at this BCR script, this is where I found this solution after almost giving up on using the new editor.
This is similar to the TEMPORARY solution I’ve implemented. Nico5 is correct - it needs fixed at the Cubase side, don’t echo back CC to the originating device, but DO send all other CC.
I have a custom controller which is just a web page served from a node.js server running on the Cubase computer. The web page (on an iPad for touch) sends OSC commands back to the node.js server which translates it to MIDI and forwards to Cubase via loopMidi ports.
I had to add a clumsy coding fix to my setup to ignore CC’s received within a certain time which were identical to those just sent - very much like Shor done. It works very well FOR MY SETUP (as Nico5 points out this is fortunate), but it’s not the solution.
It needs fixed at the Cubase MIDI Remote end, OR there is a way to do it that I haven’t figured out yet within the MIDI Remote API… but there are SOOOOO many things I don’t yet understand about it!!!
Having said all that I am a big fan of the MIDI Remote API and I think Steinberg have done a great job so far.