I’m using this one. Add double-check I’m using Cycling '74 Max.
I’m using this one. Add double-check I’m using Cycling '74 Max.
Then I don’t understand.
Any chance for a screenshot of the messages when you send to cubase, as well as the return midi?
Although I trust you saying you only get the single to and from midi, and no rounding problems like I experience.
As mentioned above.
I don’t really know how to add tags to this post, as this is now something I’d like to bug report…
Anyway, Cubase sends MIDI as a non rounded value from a 0.0-1.0 float value, and this causes certain values to send incorrectly.
A single line of code in my MIDI Script fixed this, and this is the only thing that blocks me from being able to use the MIDI Remote Editor:
var roundedValue = Math.round(127.0*newVal)
I’ll make a new post with a bug report.
edit: The delayed message, is as far as I can guess, a message Cubase sends out as a timer of sorts for throttling of messages. So that’s fine I reckon.
I’m kicking myself for not saying this earlier - it occured to me when you described your testing process with single steps and that it stalled that it might be a rounding error cause Cubase internally uses floats (so far as I could tell). I had no way to test but I should have mentioned it - seems you found it anyway.
Yeah, it’s a bit frustrating that this is the issue, as I can fix it by rewriting everything with a script, but that’s basically the only thing that prevents me from using the very nicely made GUI.
This issue of incorrect MIDI Remote behavior impacting bi-directional midi controllers including motorized faders, endless rotary encoders and touchstrips has been discussed for quite a while and I also don’t think it has been fixed properly:
In the meantime I’ve reverted back to using the Generic Remote for such bidirectional midi controllers.
It’s just less of a practical problem with on/off type push buttons, as long as one doesn’t push them repeatedly too fast.
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.
Yep I really feel like it needs a bit lot more work to get this tight.
fixed it for you!
In my view, some of the additional work needed to fully replace the need for the Generic Remote includes :
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.
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 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.
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?