Hi,
I’m getting a weird lagging ghosting of the Cubase parameter, in this case the volume fader on the channel, using a midi controller to move the fader (it also happens on other Cubase controls like panning etc tec)
Can anyone tell me what the problem might be?
I’m using Native Instruments Maschine Studio in Midi controller mode (I’m using 'Maschine Studio Virtual Input/Output as they are the only midi inputs and outputs that seem to work with Cubase ‘Midi Remote Control’ specifically.
It’s also happening with my Komplete Kontrol s25 but to a much lesser degree.
I’m not sure how to show a screen video to show the problem.
So when you move the volume control on your controller, Cubase volume is not updating smoothly?
I have a really weird similar case when using my volume fader on my controller that sends pitchbend, and I map that to volume for selected track in Cubase which sounds possibly similar.
If I sweep it from lowest volume to loudest slowly, it only updates 0-2 times or so, and the end of my sweep range doesn’t get updated in Cubase, only if I wiggle the fader slightly at the top value will the volume in Cubase eventually catch up.
However the weird thing is that my controller reflects Cubase volume perfectly if I change it from Cubase or my other controllers.
My case might be more extreme since i use 0-16383 values instead of normal midi 0-127 values.
This is what I was experiencing, I could see a ghost trail of the fader/s too.
I solved it today by setting up another instance of the Controller in “Midi Remote Control” and chose another midi output on the device. it’s all smooth now.
Before I had Maschine Studio Virtual Input & Maschine Studio Virtual Output
Now: Maschine Studio Virtual Input & Maschine Studio Port 1 (Out).
There’s no real easy way to switch midi ports once you setup the remote control, but I got there.
I’m also getting this jitter on my setup - seems to happen with endless encoders that adjust their internal value according to received CC values.
e.g. I turn the hardware encoder from 65 to 75, triggering midi CC messages with values of
65
66
67
68
69
70
71
72
73
74
75
Depending on how fast I turn the hardware encoder, the MIDI Remote (intermittently) seems to send back slightly outdated values (I’ve observed latencies of around 25ms between midi CC coming into the MIDI Remote and coming back out of the MIDI Remote (as measured via virtual midi cabling using loopMIDI on Win10).
For example, I may get an incoming CC value of 67 after I had already turned the encoder to send a 71. This in turn makes the internal value of the hardware encoder go back to the 67. And of course I’m still turning, so now the hardware encoder sends 68, 69, 70, etc - the end result being something like this:
65
66
67
68
69
70
71
67 << jitter point because of late arrival of echoed CC value
68
69
70
71
72
73
74
75
When I tested the same device (Maschine MK2) with the legacy Generic Remote, it didn’t seem to suffer from the same jitter as the new MIDI Remote.
Ohh good find!
This is for sure what is going on in my instance I think… since I use 14-bit values it’s way more noticable.
I sweep 0-16838 och the return values likely mess with this…
I wonder if there’s something that can be done here from steinbergs side? Or if you have to be creative here… I’m working on a script for this, and I’m curious if I need to do something on my end to fix this…
That sounds like it’ll fix it for sure.
How does this work for the scripts? Is there anything you need to do to controls in scripts? I encountered this very same behaviour with my fader sending (and receiving) pitchbend in my test-script.
Oh wow… I feel like a dummy now…
I put both in and out there because I’m so used to working with a middle man to send my midi back and forth to Cubase…of course that’s what I have to do. Nice! Thank you.
No worries @Shor , the thing with setInputPort and setOutputPort is not that intuitive. Though I designed it, I often forget to call those methods and then I wonder why it doesn’t work
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()
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
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
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
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.
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.
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.
In the short term, if you’re impatient like me , 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.
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 )? 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.
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
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 …
, I’ve experimented with some success, doing the following workaround:
)? 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).