Yep I really feel like it needs a bit more work to get this tight.
I really hope they can work it out, as the actual editor for setting up controllers is so neat, but for any continuous values for faders/encoders etc it’s a bit of a mess.
I just struggled in this thread to get anyone else to notice a problem.
The other thread I made reporting the rounding bug is at least part of this issue. I hope for the best once steinberg is back to capacity after summer holidays.
The delayed message I mention is probably, with a good guess, to ensure throttled messages still end up with the correct end message. This can probably be done differently, but it’s “okay” as is. The rounding error is a bigger problem.
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.
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 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)
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.
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.
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.