I’m experiencing unexpected behavior in Cubase 12.0.20 MIDI Remote (the UI based editor) with “faders” (not with “knobs”). When changing a mapped parameter inside Cubase (e.g. selected track volume), the fader in MIDI Remote mapped to it stays at a fixed location, but a “red bar” appears and is moving inside it (and it’s in fact sending out a constant/wrong value (of the fader, not the red bar), not the actual value of the mapped control). Is this a new bug? Or I’m overseeing something of course.
@Jochen_Trappe Could you confirm or disconfirm if this is an actual issue or user mistake?
Here’s how to reproduce:
- Create a new MIDI Controller Surface (via the UI)
- Add a single fader
- Move a physical fader on your device → a new fader is added, fine!
- Go to mapping assistant
- Select the fader, then e.g. map to “selected track” → “volume”, close mapping assistant
- Create a new audio track, select it
- When moving the physical fader, the mapped track volume is moving, fine!
But when moving the volume fader in Cubase, a red bar appears inside the MIDI Remote fader, and the wrong value (the one of the not moving fader, not the red bar) is sent out by Cubase through the corresponding MIDI out (to the actual MIDI controller)…
Am I doing something obviously wrong in the UI based editor, or is this a bug since Cubase 12.0.20? @Jochen_Trappe: I’m sure this is an easy one for you to answer
Could anybody try to reproduce this and report back?
Thank you all!
The fader cap reflects the state of your hardware. The red bar reflects the difference between hardware and software parameter state.
I believe @hypercube expects the value of the Fader has been sent out (so actually the “red-bar-value”) to the MIDI Out. But in Cubase the “cap” value is sent out instead in this case.
As consequence, the motorised fader wouldn’t move. Am I right, hypercube?
Thank you both @Jochen_Trappe and @Martin.Jirsak for taking the time to answer.
@Martin.Jirsak: Correct! The MIDI Remote fader in Cubase 12.0.20 sends out the “cap” (as Jochen described it) value which stays constant when moving a fader in Cubase, and not the “red bar” value.
So when moving e.g. selected track volume, then the same constant “cap” value is sent out by MIDI Remote all the time (instead of the nicely changing “red bar” value). This means the external controller’s fader is not moving since it’s not receiving the correct updated (in Cubase) value.
So this might be a bug then?
All the best
Because the Mapping Assistant sets all fader mappings to Value Mode “Scaled”. In the Script you have to explicitly set that. That’s why it differs.
Btw: are we talking about motorised faders here?
@Jochen_Trappe Thanks for replying. Ok, so it has to do with a fader’s default “scaled” mode (default in the MIDI Remote GUI mapping editor)
I’ll try to explain the issue as concisely as possible: is the following behavior expected with a fader in “scaled” mode?
If this is expected behavior with faders in “scaled” mode, I think this can be unfortunate:
- Assume an external controller’s motorized fader is at the lowest position -infinity when you turn it on
- You have a Cubase track with volume anywhere else, e.g. 0dB (let’s say you moved it in Cubase to 0dB). However, Cubase didn’t send out this new value (as described above), so the motorized fader of the external controller surface stays at -infinity…)
- → There’s now no way to REDUCE track volume with the external controller’s motorized fader, because it is still at -infinity, because Cubase didn’t send the selected track’s new volume out.
@Jochen_Trappe Does this make sense? Is this intended behavior? (I think even in “scaled” mode, once a value changes on the Cubase side, Cubase should send it out so a motorized fader on an external controller can mirror the actual new value, no?)
What do other users of MIDI Remote think about this behavior? Thanks for your thoughts.
All the best
Hi @hypercube, when having motorised faders you need to manually set your mappings to “Jump” in the Mapping Assistant.
Please see attached screenshots.
Hey @Jochen_Trappe and @Martin.Jirsak
Thanks to both of you to continually make such an effort to support your users. This is really great.
Yes, that makes a lot of sense. With “jump”, everything works as expected (I’ve noticed “jump” is default for knobs, and “scaled” seems to (now?) be the default for faders in the GUI mapping assistant)
Is there a reason “scaled” is the default for faders? I would imagine even with non-motorized faders, once a physical non-motorized fader is at an “extreme” position (i.e. all the way up or down), then using that physical fader to move a Cubase value further in that same direction becomes impossible (i.e. if a physical fader is all the way to the max, I now can’t increase any Cubase parameter, before moving the physical fader down first, which decreases some Cubase value, if that makes sense)
All the best