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)
.setInputPort(midiInput) // this causes jitter, weird behaviour
.setOutputPort(midiOutput) // this works perfectly, and without this my controller doesn't follow cubase
// 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
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
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.
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.
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.
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
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.
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
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 !
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.
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.