Is it possible to just leverage another key mapping to trigger an override of incoming automation? Yes, it’s another button press, but if it provides a way to interrupt automation feedback, maybe it’s still possible to have a complete, if not ideal, solution.
Hi, u-man. Could you give me a summary of this issue? I admit I’m a bit lost with all the back and forth over the last year.
-
Is it just a rounding error that makes the faders jitter, one that could be possibly be rectified by intercepting the output port at Bome before the messages get back to the hardware controller (and motorised fader)?
-
Does parameter “fineness” affect the issue? (pitchbend vs CC)
-
Is it none of the above and deeper than that?
Yeah, thats pretty much exactly what I’ll do if i find my current bome setup annoying. Probably a per channel “dont receive midi” button… i have my eyes on the QU17’s PAFL button 
i guess i could program a single master button instead, which would be simpler… “if write is enabled; ignore incoming midi to the qu”…
Like i said, i dont automate a channel volume a lot. I can probably live without it…
For now, stopping the midi echo feedback is working well
1 Like
I can jump in here, since I’ve been on this for half the day
“Is it just a rounding error …”
From what I can tell (and kind of prove), it’s not. It’s just a midi echo issue. You push controller; the fader in cubase moves BUT it then also tells the motorised controller to move… BUT you’ve moved the controller past that value, so the message it gets from cubase is to go back a few values and it (almost) instantly pushes back against you.
i.e. the physical fader movement is echo from cubase back to the motorised fader again.
Depending on the controller, it might even loop with some latency inbetween signals bouncing back and forth. My QU doesn’t do this though…
"Does parameter “fineness” affect… "
Yes and no… but mainly yes. Sending high resolution (e.g. 14bit NRPN) sends a LOT of echos back to the motorised fader… it pushes back more often (almost constantly) and the issue is more obvious. With a 7bit midi signal (0-127 values), it almost feels like it’s not there, but every second or so pushes back a little and would certainly cause some strain on the motor / mechanism.
The key to fixing this, within cubase (e.g. a patch) or with 3rd party programs (e.g. bome) is probably similar to what I’ve coded into bome… “If you move a fader; ignore (or don’t even send) any outgoing data from that cubase fader for a little bit”.
1 Like
Thanks!
Ok, so it’s about finding a good algorithm to swallow messages coming to the controller from Cubase. It will take some thinking.
I have an X-Touch Compact on the way, and I’m already planning things in my head, so I’m interested in a workaround (with Bome?) until the issue is tackled in MIDI Remote.
You might not have an issue to start off with!?
Does that have touch sensitive faders?? If it does it “should” disengage incoming signals automatically… fingers crossed 
If it doesnt i bome shpuld be able to solve most of these issues. No guarantees it will do everything you dream of, but it can probably get close 
1 Like
It does have touch sensitive faders, but I’ve seen that people with X32s that also have touch sensitive faders, also have some variation of the same issue, so I’m already in troubleshooting mode, educating myself about it.
Bome is incredible software. Genius. Not easy, but what is easy in this life? I’ll be alright I think, compromise is in my blood. 
Ah ok… right! Thats a shame, but at least i dont need to wish i had touch sensitve faders lol…
Bome is a beast for midi, and ive got it solved for my needs with a half day of trouble shooting (understanding the issue) and then programming… So thats a good back up plan…
If i get around to tidying up my bome code, I’ll post the basic concept here for others. At the moment its pretty long winded but can probably knock it down to 3-5 translators.
1 Like
That would be awesome. You’d save me a lot of time. 
Hi again…
Ok - have it all working really nicely. For the sake of not letting down people who have read the BOME ideas in my comments above, I’ll take the time to quickly (well… probably a long post!) explain the concept I’ve adopted. I won’t necessarily have time to help people with individual units and differences in e.g. CC or NRPN values, but from here you should be able to get things up and running, OR jump onto the BOME forum with questions if you need help with what this is meant to be doing…
SOLVE FADER ECHO / FEEDBACK USING BOME:
Disclaimer - I have no control over what this script does to your unit!.. I can’t imagine it breaking anything; but I’m certainly not responsible for what happens if you use this approach. It’s also possible that there’s a better way to achieve the same thing - I’m not a BOME mega-expert…
As per my posts above, the issue is that a motorised controller can send data to a cubase fader BUT the fader echos that command back to the physical fader… This makes the fader push back against you and could cause damage to the fader.
What we need to do is stop the Cubase messages coming back to the fader - to do this I’ve chosen to use a script that tells the controller to ignore messages for a short period after a fader has been touched.
Limitations / drawbacks…
Before we kick off, there are some drawbacks (or at least, some key things to be aware of) with this setup…
- You’re no longer connecting to Cubase directly with your unit…
You will be connecting to Cubase using the BOME virtual driver. This MAY mean that you will need to map EVERY command your unit has into bome, which could be quite boring and tiring. I’m actually going to do this on my QU16 because I like the additional fleixibility of what bome can offer, but if you “just want your faders to work”, mapping every command might suck…
Possible workaround… You MIGHT be able to only do faders, and and use the BOME virtual driver for that in cubase, and then use the actual controller driver for the other functions… this will act like two separate controllers in cubase… and I’m not sure that it will work (not sure if the unit drivers will be happy to be working in bome AND cubase at the same time)… You can try it out if you like…
- It doesn’t magically turn a non-touch sensitive controller into a touch sensitive controller…
I’ve noticed on the QU16 that if its receiving fader control message BEFORE I touch a fader, it overrides me moving the fader and my movements aren’t registered and the script doesn’t work 90% of the time. It’s almost like REVERSE touch sensitive lol… This basically means that I’d be hurting the controller if I try to move it AFTER it’s already being automated…
This also means I have to be moving the fader BEFORE it receives fader automation from Cubase. I’ll possibly develop a workaround which disengages “read” for automation with a button press on my controller for when I’m wanting to move faders which are otherwise automated.
- There will more limitation that you’ll find… I might not have the same intent as you
e.g. I can’t seem to get latch modes working in Cubase… but I don’t care!..
The Basics of the scripts
There are two ways you could do this… Write translators for EACH fader separately (takes a long time, a few extra options might be available to you); Or write one basic command for ALL faders, using variables to update data depending on which controller your moving (which and simple – this is what I did). The basics below should apply to either approach, but it’s worth noting those options.
NOTE: I’ll talk about “CC” because it’s easy to type… you’re faders may be e.g. 14bit NRPN, but the basic intent is the same…
What I need to do is:
- Receive fader movement data from my QU16; and pass it on unaltered to the Bome midi driver
- Run a timer that creates a window of time after the fader is moved
- Tell Bome to stop sending fader data from the bome virtual driver to the QU16 for that amount of time
To do this I used four translators:
1st Translator Send QU16 to CB
This takes the fader movement and sends the data to the bome virtual driver (which arrives in Cubase)
Incoming:
Channel: Whatever channel your fader(s) are on
Midi CC: QU16 midi fader use 0-15… You can use the actual value (for programming individual faders); OR “any value” and “Set Variable” and assign as a local variable (simple) – e.g. “oo” (which is what I did).
Value: “Any value” and “Set Variable Value”… use a local variable that’s different to the CC local variable (if used) – e.g. “pp”
Select MIDI Port: select you unit… e.g. QU16 Midi port
Rules:
Rules may be optional… I’ve included “if pp>=16 then exit rules, skip Outgoing Action” so that the script only runs when the 0-15 CC faders are moved.
Outgoing:
EXCATLY the same as the incoming; Except change the outgoing midi port to “Bome Midi Translator Virtual Out”
2nd Translator: Timer – initial step
Here the intent is to use a GLOBAL variable (e.g. “ga”) to toggle between “ON” (e.g. ga=1) and “OFF” (e.g. ga= 0). This translators role is to send the “OFF” message AND then also start a timer… That’s all.
To do this, we want “when fader moves; set ga=0” and then also “run timer”…
Incoming:
Identical the 1st translator, although you don’t really need to set a variable to “Value”… but it also doesn’t mater if you do… we’re just not using it for anything. It just needs to be set to “any value” for it work…
Rules:
if pp>=16 then exit rules, skip Outgoing Action
// for the same reason as I mentioned… but the important part is the ga=0 below
ga=0
Outgoing:
Type: TIMER
Name: whatever you like… I called it “Fader Moved”
“Once”
Initial Delay: I’m using 600ms
NOTE: The 600ms is how long after you stop moving a fader until that fader will start receiving values again. I’ve noticed (for my setup):
500ms or less – the fader will receive the actual existing Cubase fader value (if present), and snap back into place;
600ms+ the timer is still on for longer than the it takes for Cubase to send back a final existing fader value, so fader stays where you left it.
This only really matters if you’re e.g. moving a fader in Cubase that has automation while you’re not hitting play… The Cubase fader will snap back but the physical fader may not if you’re setting 600ms or more… This means the controller might not be showing the ACTUAL fader value for 600ms+ timer settings after you hit play again… To snap it to actual Cubase values, you can toggle “read” on and off, and it will snap to the actual value… OR use values less than 500ms (or experiment at your end). I’m using 600ms because I’m trying to avoid crunching my faders - e.g. in testing several times I had my hand on the fader not moving, and the timer would reset and it would fly back to the cubase value.
3rd Translator: Allow messages to be received again
We use the above timer to trigger this event, which then says “ga=1” again… i.e. “ON”, and we can receive messages from Cubase again…
Incoming:
TIMER
Timer Name: whatever you called it… I called it “Fader Moved”
Rules:
ga=1
Outgoing Action:
None
4th translator: Send CB to QU16
Here we want to receive Cubase messages, and pass them onto the controller (opposite of Translator 1) BUT set conditions to ignore these messages while the “fader moved” timer is running (i.e. when ga=0)…
Incoming:
Identical to 1st translator EXCEPT set the Midi port to “Bome Midi Translator Virtual Out”
Rules:
// This will stop it from sending data to controller if ga=0
if ga!=1 then exit rules, skip Outgoing Action
// I’m still using my 0-15 CC filter too, specific to QU16
if pp>=16 then exit rules, skip Outgoing Action
Outgoing:
Identical to 1st translator EXCEPT set the Midi port to your unit (e.g. QU16 driver)
////////////
And we’re done… although note: You should probably also setup an “Initialise” translator that sets e.g. ga=1 upon project open, just for thoroughness
OH… and there’s one final things I’ll be working on - I’m still experimenting with some timer settings - ideally it is told to “restart the timer” every trigger - I think at the moment it technically runs a separate trigger for every value that times out individually (set’s ga=1) which MAY cause a tiny window for echo again… I’ve not noticed any issue with the way it’s working; but I’ll update this post if I refine it more…
So – yes, it did end up being an epic post. Sorry for all those people who need to scroll past this… BUT I hope it can help someone out there who is having motorised fader issues like me (us)…
2 Likes
This is great! I appreciate the thorough reply, I will fall back to this method if (when) my experiments fail. It’s interesting that you approach the solution from a time perspective.
Just thinking about it, I was thinking about establishing “simplex” communication between the hardware fader and Cubase. Something like this:
When the hardware fader is receiving values, they will not be sent to the hardware’s output port (to avoid having them in Cubase again). And when the hardware fader’s touch sensor is live, any incoming messages to the fader (because obviously I can’t just tell Cubase to stop sending messages back) will be swallowed.
I am sure that there’s some catch to this, but I can’t plan many moves ahead. I’ll just have to see it in practice.
Still not fixed in Cubase 13 - Come on guys.
Not fixed in 13.1
Touch sensitive faders are supported since version 13.0.20.
Thomas
My M32 still jitters and fights if I enable it. Its still unusable.
Thanks for checking this Pauly, holding off on upgrading to Cubase 13 while i still have the M32
The problem could not be caused by cubase / nuendo.
On this forum, you can find many scripts dedicated to MCU clones, they all work using motorised faders, and they were working since v12, before the support of touch sensitive devices.
A quick glance at the m32 manual tells me it’s Mackie Control compatible. So it should be compatible with most if not all scripts for Mackie Control devices here. Like this one from @bjoluc : iCON QCon Pro G2 (+Extender) MIDI Remote Script
Hi Thomas
The Mackie control has always worked with this breed of desk - both the x32 and m32 implement it fine, however it’s 8 faders at a time (bus faders) and really would only work efficiently for projects where you could work it out to only use 8 faders. (I should add, I’m talking about me, not everyone. Perhaps someone can use this 8 fader method to do great mixes- not me)
When steinberg announced the remote interface, and how it could work with digital desks I was over the moon, thinking I could finally use hardware to do a mix. Here we are, what 13 months later and the new remote feature still doesn’t work on x32 or m32 desks.
If anyone else that has a digital mixing desk with moving faders (more than the 8 from Mackie control) that is usable as a hardware mixer for Cubase using the new remote feature, please chime in.
Thanks
Pauly
1 Like
Mackie Control protocol can make use of to 32 faders (plus a master fader). But maybe the M32 has only one MIDI port.
However, if it’s working fine in Mackie Control mode, and every other controller can make use of MIDI remote with motorised faders, maybe there’s a problem with your script or your device. Have you tried to report this issue to Midas / Behringer?
EDIT: I’ve reading the m32 manual a second time. It isn’t very clear but it seems that only the group faders are available in “Remote” mode (m32 Remote mode).
So, if you want more than 8 faders, I’m afraid that you would need another console / controller.
Bests,
Thomas
Thanks for spreading the word @thomas_martin
That’s certainly right for the MCU part. Luckily, as far as I understand, the “Generic CC” mode can send and receive all faders’ positions via one MIDI port. But it seems to only send out fader positions with a resolution of 128 steps and it doesn’t communicate whether a hardware fader is touched. In Cubase’s default Mackie Control implementation, Cubase just doesn’t transmit fader positions while a fader is touched.
@Pauly If you can convince Midas/Behringer to transmit fader touch states in “Generic CC” mode, it should be possible to make this work cleanly with the MIDI Remote API and a little bit of Javascript (which I could help you with). Maybe another option (Javascript MIDI Remote API too) could be to not send out fader positions for a fixed time after receiving the last fader position from the M32.
I agree it’s a pitty that this doesn’t work with the MIDI Remote Surface editor out of the box. I think it would work if Cubase provided an option to only send out CC values when they are not the consequence of an identical incoming CC message (which doesn’t sound trivial to me, at least).