Midi "ghosting/Jitter" Cubase 12 with midi controller encoders (Midi Remote Control)

I found that it is related to the new takeover function. Suppose “Jump” will response to the exact value to the received midi value, but I think there is some algorithm done there maybe. The actual behaviour is like the movement is not smooth and sometimes it move little backward. I tried using “scale” will response better, not glittered but will have less resolution (the modulation will be more “jumpy” than in Cubase 11). I think it is because of the scaled factor. The “pickup” mode will act terribly.

When the MIDI Remote Mapping Assistant dialog is open, both the knob in the dialog and in the MIDI remote will react smoothly. But not after it is closed.

I hope either looking if the takeover jump mode can have something to fix/improve, or add a takeover mode that act exactly the same as Cubase 11 (nothing can be set). I think this will also affect any hardware device that provide modulating midi message as input.

Not sure if you read this entire thread in detail. – This is a known issue with an already known solution on the way.

Specifically my old post, showing that it’s related to the input midi message being echoed back with some latency: Midi "ghosting/Jitter" Cubase 12 with midi controller encoders (Midi Remote Control) - #5 by Nico5

And Jochen already replied, that a solution is on the way, via being able to suppress the echoing:


p.s.

Yes, because scale will make the target controller respond more gently until it crosses over the current internal Cubase value. Once it has crossed over, it will be the same as jump.

Yes, because when that dialog is open, the messages don’t get passed to Cubase and thus no echoing of the message occurs. Also see this post by Jochen: How to change MIDI Remote MIDI port after creation? - #8 by Jochen_Trappe

1 Like

Thanks so much for the explaination because it was quite difficult to understand. Now I have much better understanding. Wait for the fix =)

1 Like

You’re welcome - it’s indeed quite a rabbit hole!

In the short term, if you’re impatient like me :grinning:, I’ve experimented with some success, doing the following workaround:

In the new MIDI Remote:

  • Map only the buttons and non-endless knobs on my hardware with the new MIDI Remote.
    • i.e. Leave all endless encoders unmapped (not even mapped to the hardware) in the new MIDI Remote

In the old Generic Remote

  • Map only the endless encoders

And once the next Cubase update rolls in, I’ll just add the mappings of the endless encoders to my new MIDI Remote template and delete that Generic Remote.

1 Like

I’ve set the midi out output port to a different device and yes the jump acts exactly what I want now. Hmm… I think I still have something not fully understand. The issues is caused by the MIDI remote send out the midi message to the loopback device in my case, and I also have track still keep sending midi messages out to the loopback device, doesn’t it cause an infinity loop (like those audio feedback :sweat_smile:)? Is it because the MIDI remote knob will act frame by frame, multiple messages received within the same frame will only have 1 to be chosen as active (like what those game engine, realtime-like turn based network game).

If you don’t have time, just ignore me. I’m only curious. :sunglasses:

Generally, most remote hardware doesn’t echo incoming midi messages, that’s why it doesn’t cause a midi feedback loop.

But just the other day, there was somebody who had built their own midi hardware controller and it echoed the incoming midi messages, leading to exactly that - an endless midi loop freezing his Cubase :slight_smile:

p.s. I was able to identify the problem for him, although he gave himself the credit for the solution in the forum software. Oh well, some people …

1 Like

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
    • via automation
  • 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.

3 Likes

I found pickup modes always worse than “jump” even on non-motorised faders. But how else should the pickup mode behave?

1 Like

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

Hi again,

The issue is not solved for me either. My M32 faders just lock up and are useless.
Any hints on a solution?
Thanks
Pauly

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 !

I did little more testing and I have problems only with VST2 plugins with VST3 everything works normaly… Dont use control surfaces, only midi controller for contorlling some parameters.

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.
Thanks
Pauly

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.

1 Like

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.

1 Like

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).

1 Like

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 :frowning_face: