Haha I approve of your fix.
I agree entirely.
The one thing I’d put up highest in priority though is correcting the rounding bug, as that’s actually a really really frustrating thing when trying to adjust something with as fine detail as you can with midi.
Midi Remote basically needs only to be supported in the RCE. That would cover nearly anything you mentioned.
This: Step-By-Step Guide for using the Remote Control Editor
We as users really need to push this. Maybe creating a poll thread. If Midi Remote would be supported, I would be entirely happy 
.
The rounding problem is there, because Cubase deals everything entirely with absolute values (1-127), except the mix console faders. We on the other side are using relative values with endless encoders and motorized faders. So the whole process of transmitting data is sadly a downgrade by converting relative values to absolute values, which in turn can cause rounding errors.
I do understand Steinberg here, as 1-127 values are enough most of the time, but there are cases, where 1-1024 would be fantastic, i.e. EQ Freq. , Cutoff-Resonance sweep spots etc. etc.
I think you have a bigger problem with the extra messages send after your initial one. This is something I can’t confirm and I wonder what could cause this.
Since this should simply not happen.
This is actually not true.
Cubase handles values internally with floating point decimal values. Typically from 0-1, and when these are ‘converted’ back to midi values 0-127 they actually aren’t rounding them correctly. After they calculate it to 0-127 range, they drop the decimals, and keep the integer portion of the number.
This results in numbers like 79.9999 becoming midi value 79, instead of rounding it to 80.
I tried this with the javascript api and I can fix this problem myself.
I believe this is a delayed message that gets sent just to ensure that no values are lost, since Cubase throttles MIDI messages (in a very efficient and nice way mind you). But it’s not an ideal solution, and this could definitely be improved.
For every midi device you map up that is bound to the same controls, you get one additional message here as well, so it gets unnecessarily spammy.
While I have zero insight on Steinberg’s internal architecture and decision making process, I do have the funny feeling, that in Steinberg’s view the new MIDI Remote and new Focus Quick Controls are their own brand new code and API ecosystem, not reliant on the Remote Control Editor, the Generic Remote, or any of the currently existing hardware mapping mechanisms.
They may be unwilling or unable to touch some of that old code, and may have decided to deprecate all of it.
If you are interested, I made a generic function for creating controls (just knobs for now) that at least solves all my issues in this thread.
Rounding is done correctly, and midi isn’t sent back to the controller that sends a value, but it will receive midi if another control changes said parameter.
I do feel this is still a bug in Cubase, as I don’t feel you should have to make a script yourself for this.
I have this same issue in Nuendo 12.0.4. I’m building a controller from scratch using rotary encoders and regular pots, so I have a lot of control over how messages are sent and received.
I first built it for a relative encoder (binary offset), which worked very well. However it is too specific to Steinberg so instead I converted it to absolute mode. I am also seeing the double messages and incorrect rounding, and it causes the control to get stuck in some cases because it always rounds down.
This is an example of the readouts I get, where I am sending to Nuendo from my controller and monitoring all sent and received messages: (using CC 1 in all cases)
Send: 64
Receive: 64
Receive: 64
Send: 65
Receive: 65
Receive: 65
Send 66:
Receive: 65
Receive: 65
Send 66:
Receive: 65
Receive: 65
Send 66:
Receive: 65
Receive: 65
I cannot increase the encoder value past 65 as in the above example, likely due to the bad rounding.
There is a duplicate receive message after a short delay, but that does really affect the functionality at all. It only happens when changing a value with the mouse or from the hardware control. Changing the control using the mouse wheel does not send these double messages. I think it has something to do with touch sensitivity - I will investigate this further.
I actually do prefer the return message, as this drives the LED ring around the encoders. Obviously this would not work for motorized faders, there should be a separate option for defining this in more detail.
If you have found any other solution, please let me know.
I wasn’t aware of the JS script API, thanks for posting. I’ll give that a go.
Thanks for replying and posting the results. You are actually the first to actually post findings.
But yes to me this is clear as day a bug, and I hope it’s fixed soon by Steinberg.
There’s no fix other than to write your own controller script. I did fix it with the script I posted a snippet of, but you’d need to modify it a bit if you want to receive MIDI feedback back to your controller.
It wouldn’t be too difficult to fix for Steinberg, so I am optimistic. The biggest thing for you is the rounding error, which you can probably work around quite easily I hope. It’s just a shame that this single thing makes the entire mapping assistant entirely useless, as you’d have to go either mapping assistant or a javascript. A hybrid would’ve been welcome here.
I agree. At least an “advanced options” tab in the GUI that lets the user specify more detailed behavior, using the same parameters available from the API. Like multiple options for handling “Transmit to Hardware”.
One thing that bugs me is that you can use 14-bit resolution in absolute mode but not relative mode. It always reverts to absolute when I switch to 14-bit resolution. This makes relative encoders limited to 7-bit messages. I don’t mind that too much, but it means a fader can never actually return to 0.0dB. (which sits between CC value 95 and 96.)
I came up with a knob “acceleration” method that changes the knob resolution based on how fast you turn it. It’s great for quickly dialing in large changes, but still retaining fine control when you turn slowly. It feels natural and works well in relative mode, but it’s still limited to 7-bits. I guess I have to live with that.
So far I’ve only tried the GUI remote device manager. I’m diving into the API now, maybe I can do it from there.
I tried the custom smartKnob script posted above, got it working as expected - thank you for that by the way @Shor.
However, for my purpose I still need MIDI feedback for the relative encoder position. I modified the smart knob to send Midi when the Cubase knob is adjusted, and I still get the doubling message behavior as before. Weird.
I may have to modify my approach. I’m thinking if I track CC values in the hardware, and still allow cubase to set them if CCs are received, I can make the encoder behave as an absolute knob (for use with any DAW) or use the smartknob function so it follows automation etc. That’s tomorrow’s problem.
Oh that’s awesome that you got it (mostly?) working.
I kind of just hacked it together just to make it work for my setup, with hopes that it’ll be possible to do in Cubase eventually, so the code isn’t very neat.
It doesn’t work properly with relative settings unfortunately, due to how I am handling the logic about not receiving MIDI feedback. Basically I check to ensure that the value I send is the value Cubase thinks the parameter is, and this wont match up well with relative values. It does work, just a bit imprecise.
It is definitely made for absolute values.
Definitely keep us up to date if you think of any clever ways to work it out.
Has anyone had time to see if this bug was fixed in 12.0.50?
Still a bug in 12.0.50
So is there still no reliable way of using relative encoders with feedback without getting a bunch of rubberbanding/jitter?
Seems so, unless you write your own javascript for your controllers.
I have only been using the JavaScript API.
At least before the .50 update, there was no way of scaling controllers that send relative values. They were always scaled as being 7bit values. That made me start using the API instead. But still I haven’t been able to get the encoders jitter free. Especially with fast encoder movements.
Ohh right of course.
Yeah I made an adaption to handle encoders and faders without jitter, but relative is not as easy to manage.
I am more concerned with the Midi Remote Editor bugs with sending incorrect and extra values not being fixed with this update.
Any word on if this bug is something that is nearing a fix? It’s really frustrating to not be able to make use of the MIDI Remote Editor, since it does look so nice, and is easy to use. But at the moment it is unfortunately entirely useless for any control that requires MIDI being sent back to it.
I’m using Lemur and I wanted to set it up to Midi Remote.
The irritating thing about Midi Remote is that it refuses to allow you to change your MIDI Input/Output Ports once you’ve set them. Right now, I’m experiencing the same thing you are - alot of jittering and lagginess. I have a feeling it’s to do with some MIDI feedback loop of some kind.
Generic Remote doesn’t have this problem at all.
Completely agree!