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

I had a chance to try this quickly over lunch, and this actually has me stumped.
I need the midiOutput to receive the changes from Cubase.
Without it it wont follow.
The midi input is where it seems to break, and then I get this very weird throttling feeling behaviour.
I have no further time to analyze this right now as I need to get to work, but this is all that’s in my script now.

var fader1 = deviceDriver.mSurface.makeFader(0, 0, 2, 8)

fader1.mSurfaceValue.mMidiBinding
	.setInputPort(midiInput) // this causes jitter, weird behaviour
	.setOutputPort(midiOutput) // this works perfectly, and without this my controller doesn't follow cubase
	.bindToPitchBend(0)

// create at least one mapping page
var page = deviceDriver.mMapping.makePage('Mixer Mode')

// create host accessing objects
var hostSelectedTrackChannel = page.mHostAccess.mTrackSelection.mMixerChannel


// bind surface elements to host accessing object values
page.makeValueBinding(fader1.mSurfaceValue, hostSelectedTrackChannel.mValue.mVolume)
    .setValueTakeOverModeJump()

1 Like

i have noticed the same jittering as described above, i use the behringer X-touch Mini and the Faderfox UC4 (in absolute mode)
the thing is, if we deactivate the midi output send from cubase, how will the controller be able to show the correct value on the LEDs for example? the LED Indicators on the controller are an important feature, if we turn up the midi-feedback at all, those wont work anymore :frowning:

when i did set the controllers to “scale” mode in the setting, the jittering was gone or less noticable, but of course, the scale mode does not work well for all use-cases. this jitter did also not happen to me in the “takeover” setting, only in the “sprung / Jump” default setting for rotary knobs.

its seems like the jittering is coming from the new cubase remote algorithm that does interpolate the values, in the legacy midi control this was not an issue because there was no interpolation happening. you got these smooth curves, but also limited functionality compared to the new midi remote control.

I really love the new midi remote control and its feature, and i hope the algorithm of the interpolation will be improved (or what causes that jittering) so that we dont get this jittering anymore and will be able experience smooth control of the parameters as intended :slight_smile:

cheers and have a nice weekend
Chris

Edit: after having played around with it a bit more, i found that when i change the hardware setup my midi controllers from absolute mode to relative mode, and also adapt the midi controller script in cubase to reflect that change, the jitter issue was gone and it was still able to keep the output to the midi controllers as well so that they show the correct status via the LEDs :+1:

I was able to eliminate the problem (I think) by simply choosing a midi output in “Midi Remote Control” setup that didn’t directly correspond with the input. I guess this would only work on devices that offer more than a single midi in and out.

1 Like

I’m not sure if it is the same issue. I am getting problem using the trick illustrated in the following video to loopback midi to modulate parameters:

I tested in Cubase 11 it was work as expected. However, I do the same thing in Cubase 12 with MIDI remote ghosting/jitter occur on the encoder as well as the mapped parameter. However, I found in the mapping dialog the encoder rotates pretty smoothly without any jitter as shown in mapping.png

I also tried to do the exact same thing in Cubase 12 to create a Generic Remote (Legacy) under Studio Setup. But the result is even more terrible… the mapped parameters only occasionally response to the mapping.

Spec:
MacOS 11.6.5, using IAC Driver for MIDI loopback driver.
Latest version of Cubase Pro 12 and Cubase Pro 11


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