MIDI Remote sending delayed (and incorrect) messages to my controllers

Please :slight_smile:
@Martin.Jirsak if you have any input it’d be so valuable.
Same result on 2 computers

The only time I’ve seen lag with it, is when I have the debug console open - I guess you’re not running that as you’re using the mapping assistant?

Looks like an internal issue with MIDI Remote to me, but not sure how anyone outside of the dev team could confirm this really?

Hi,

Sorry for my delay.

I have tested this today. I couldn’t reproduce it the way you described.

I have attached the fader to the Volume of Selected track. Then I moved the fader in Cubase slowly up. I can confirm, some MIDI Values ere skipped in the MIDI Monitor. But when I hold down Shift and move the slider (use the scroll-wheel) to get higher precision from Cubase, none of the MIDI values (0-127) has been skipped.

I haven’t seen the values would go forward and backward.

Damn that’s so weird…
Btw I did set mine up to do the mouse AI control when I had this behaviour.
I’ll try the shift + move later. Thanks.

I’m so puzzled. Thank you.
Do you mind showing me a screenshot or something of how you set it up? I just want to try to narrow this down because it’s driving me a bit bonkers :slight_smile:
I don’t know if I can simplify it more on my end by now.

In the coming week or so I think I’ll try to take some time to write a script to see if I can make it work better.

Yeah I’m using the mapping assistant.
The thing is, I am not getting lag exactly. I get a very fast response from Cubase, but shortly after I get another message, and this is the one that’s sometimes rounded incorrectly, causing values to sometimes behave like in above screenshots.
So I can go from say… cc value 55, move fader to 56, cubase returns 56 and then shortly after returns 55, and then I can’t move past 55 unless I move faster so I get past 55 quick.

Hi,

Here are some screenshots.

Thanks.
No matter how similar my controller is set up to yours…nothing behaves like it does for you unfortunately.

Right now I have it set up just the same as you. I click it up to cc value 80 from 79, and Cubase sends me back 79…click one step up to 80 (btw it’s consistently hitting me back with 79 if I click up to 80 from 79).

It happens no matter which track I have selected amusingly enough. If I swipe across values faster/normal speed, it works fine. But when I do very slow clicks one at a time I keep getting this…

Will try to dive in with javascript later, but it’s frustrating you can’t reproduce it. I just can’t think of anything in my setup that is in any way different now.

@Shor Just noting this comment from @Martin.Jirsak - are you absolutely certain its not your monitoring giving you a false reading or a delayed one?

FYI, I can’t reproduce the behaviour you are seeing with either of my controllers - one is motorised and would jump about under the conditions you’re illustrating.

Must be terribly frustrating.

Hi,
Thanks for taking the time to sift through this.

My monitoring is dead on. I confirmed with both snoize: MIDI Monitor as well as one of my controllers having monitoring built in, so I can see the phenomenon happening there as well.
Btw his comment about some values being skipped is actually how Cubase throttles MIDI messages if messages are changing rapidly. It is great, as it ensures we aren’t getting unnecessary delay due to massive MIDI spam.

Anyway, I have motorised faders as well haha…so I can sometimes hear the motors whirring but not really doing much of any movement.

The delayed messages only happen once I’m done moving my controls though. So while moving controls normally, it’s all fine.
So once I stop moving my controls, another set of messages is sent out to them.

Today I’m going to just delete every one of my midi control setup scripts, and do everything from scratch (again).

Btw when you say you can’t reproduce my problem. How are you testing it?

To me, the easiest way to test it has been to set up a control to be absolute value and transmit to hw.
Then set it up to be mouse value, and hover over a volume fader. Then midi value by midi value I increment up from say… midi value 40 or something. For each value I increment I monitor in my external MIDI Monitor application, as well as on the value on the volume fader in Cubase.
Eventually I come to a value where a tick on my controller doesn’t do anything at all in Cubase, and then I can see my MIDI Monitoring saying my controller sends value 80, and then Cubase returns 79 to me…so I get literally stuck there, unless I move my controller faster so it sends a minimum of an increment of 2 or more.

@Martin.Jirsak sorry to tag you again on this seemingly endless thread. But what I’m missing from your reproduction is actual output from a midi monitor.
I kind of feel this might be a developer issue potentially, as this seems like a rounding bug to me. But you really do need to examine the midi data to see it I think. I experience a very slight jitter as well due to this when I change values.

Ok… all MIDI configuration cleared… only this Faderfox MX12 controller connected, and I made a new midi remote editor setup for it.

It has a single encoder, and it only does send and receive selected track volume.

Below is the behaviour I get in the midi monitor by snoize.
Observe: I mouse over volume fader, and I get midi value 79 to start with, and then I increment the controller one click to midi value 80, and I quickly get a return 79 from cubase, and then about 500ms later I get another 79 back. This behaviour repeats.
Please check the time on these events. They come in triplets. One “From” message is paired with 2 “To”-messages, where the 2nd of those is delayed.
Also observe me sending 80, which gets a return of 79.
If you check the list in midi monitor you see that for certain from values I get the correct value, which is why I am thinking this is a problem with rounding (or not correctly rounding) a floating point decimal to an integer.

If anyone would try to reproduce this, please ensure you have a MIDI Monitor so you can see all messages with timestamps from your devices, and just do increments of one.
There’s no way I can make this any simpler to reproduce. Unfortunately I don’t have another computer I can try this on.

This is the setup for said device, and it’s the only device I have in Cubase:

Hi,

Isn’t there MIDI loop back at your system by any chance? Doesn’t your hardware send the incoming MIDI data back to the output?

No, there is no loopback unfortunately.
I tried this in a more simplified way as well by just connecting my Arturia Keystep and doing a simple modwheel controls volume thing, and I experienced the same thing with only the Keystep connected to my computer.
Unfortunately since that uses a touch strip to do control it’s a bit harder to do an exact test.
But it did do the same behaviour with a slightly delayed message coming after.
I tried this in an empty Cubase Project as well with absolutely nothing going on. On my other computer I tried this experiment in Cubase Elements as well…same result.

I just now attempted this with the Generic Remote (legacy one) as well, and I noticed that it doesn’t return the message to the device sending the MIDI message in that one. But when you move a connected control (i.e. drag volume fader with mouse), or control the same control with a different midi cc, it does send MIDI to any of the other controllers that have the same mapping… so that works better, and causes zero “extra” messages.

To me this feels very isolated to the MIDI Remote mapping assistant setup. If you can run some example output from a midi monitor software that’d be really interesting, as I do feel like you should be able to observe the same behaviour.

Again, I unfortunately don’t have a way to run this on more computers on my end, as I don’t have any other test candidates here, unless I fire up an old PC, but that feels more effort than it is worth at this point.

If you run Mac on your end, I’d highly recommend the Snoize Midi Monitor software as it’s pretty good for these trouble shooting tasks.

Hi,

I’m using this one. Add double-check I’m using Cycling '74 Max.

Oh man…
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 started trying out hacking this together myself in a javascript now, and I tested out one of my theories by rounding the value from cubase before sending it to midi, and this solved my problems.

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.

#issue

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.

1 Like

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.

I really don’t want to revert to the generic remote again. I feel like I can make it work decently with a javascript.
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.

1 Like

Yep I really feel like it needs a bit lot more work to get this tight.

fixed it for you! :slight_smile:


In my view, some of the additional work needed to fully replace the need for the Generic Remote includes :

  • managing bi-directional controllers correctly
  • remote controlling Insert FX chain
  • facilitating different MIDI messages for sending vs receiving
  • facilitating controls by position (e.g. controlling the 3rd VST automation parameter, regardless of whatever the current target instrument or fx is)
  • XML file editing of mappings
  • handling Program Change messages and Polyphonic Aftertouch MIDI messages
1 Like