Midi Remote does not react fast enough to channel changes?

Cubase V12.0.52 Build393 Win10:

When you have a remote controller controlling “Volume (Selected Track)” and you select a track and immediately start moving the fader, for a second or so, the Volume of the old unselected channel is moving, before the current volume fader starts moving.

So it is not possible to work quickly. You’ll always have to wait for a second, otherwise you’ll change the previously selected channel volume.

Just tested it again and found out, that the delay of selecting the channel until the controller controls the newly selected channel varies.

Selecting another channel in the project view only causes a small delay.
Selecting another channel in the mixer causes a larger delay until the control controls the newly selected channel.

Hello bemi,

Did some ‘critical testing’ and I agree there is some ‘reaction time’, but far less than a second.
I use a Faderport V2, with a MIDI Remote script. (So not the Mackie emulation).
But, I wouldn’t call it a bug …
What controller do you use and any specs of the PC you want to share?

1 Like

Maybe it is not a second, but a few hundred milliseconds. And as I said, the delay differs. Switchen the tracks in the project windows is faster than switching the track via the mixer windows.

Never the less, I would call it a bug, since the user can expect that after selecting a new track, that sending a volume change on the selected track should not effect the unselected track anymore.

I’m writing my own controller and one of the ideas was to select a track and then performing one operation on the newly selected track. Since its done by software, sending out e.g. volume on selected track follows immediately after the track selection. The software does not know, how long it has to wait. Nevertheless, this was manual testing. I did not test, if this is a problem, when selecting the track via RemoteControl also has a delay. So I am not sure if this gets a problem.

But Steinberg should repair it. The delay is very noticeable.

Well, they won’t repair it since it ain’t broken.

But you are entitled to your opinion of course.

But what about your PC specs? Controller used?

Sounds interesting. Could you elaborate on this work in progress of yours?

It’s a windows app, that can remote control Cubase. Some parts like the mixer shall work via CC messages so you can change them all the time even if the mixer is not visible (already working with the old Generic Remote implemenation) and for the rest I capture the screen where Cubase is running and transmit it to my remote controller (Windows Tablet). Then I can interact with this image of the Cubase Host and can use Touch, Mouse and Keyboard of my Surface Pro to send user interaction back to Cubase faking Mouse/Touch/Keyboard input as if I were sitting in fron of the Cubase computer. Also found a way for some plugins to capture them, when they are in the background, but is sadly this is not working for Cubase/Steinberg windows. But I worked with Omnisphere and some other.

Sadly there is not real SDK to remote access every part of Cubase from a different application.

I am impressed.
I have a Surface Pro 3 (so you have my attention) …

Just for info: There is an iPad Cubase app that is ‘quite fantastic’ already.

Since I have no Apple shares, I don’t buy their products :slight_smile:

It shall become more than a remote controller, it shall also become a librarian/editor software my hardware synths and some kind of a performance sequencer → do something on the touch screen and it fakes me playing midi notes :wink: I can already sync to Cubase Midi clock, but the rest is still missing.

It shall somehow be a limited controller for 80ies tape machine style recording. So prepare a 16 track project on the PC and do all the rest from the remote controller. First I thought about a hardware multitrack recorder, but since in the end you would go into your DAW, I thought, create some Multitrack recorder looking UI, but use Cubase/DAW in the Background. So best of both worlds.

Maybe I am less a musician than a programmer.

This IS a bug. Before the update I did not have this issue and since the latest update, this issue makes my use of my controller useless with this delay. The idea with mapping controllers to virtual faders is to simulate a hardware desk. This is not correct behaviour…

1 Like

WHY IS THIS NOT FIXED? This is driving me mad

1 Like

I would also like to see this fixed. Things don’t behave as a normal user would expect and remote controller don’t work reliable which means they don’t work at all. Nobody would use a remote controller, that does changes to a not selected track.

I noticed the delay too. It needs of course a very fast user’s action, but, sure, it’s there.
The way I understand it, is that upon a track change, many many parameters change and can trigger events. This leads to latency, but surely it can be optimised by giving priority to volume/pan.

A workaround in the mean time, might be to bind your control to multiple other custom variables, based on the index of the selected track, and then bind these custom variables to a mixerBankZone’s tracks, hoping of course that the “selected” event will fire straight away. It gets a bit complicated though and not sure it’s worth the effort.

Anyway, on some testings I’ve done, I’ve noticed that the latency is more when we have the Mixer Console open, and in my setup it gets up to 70ms. The following screenshot demonstrates a track change (from track 7 to 0) with immediate volume change.

When we have Mixer Console closed, the delay drops down to 10ms, but again this leaves time for the unwanted change in volume to happen. (Changing track from 2 to 1 here).

In my mind, the root issue here is that you have to select a channel before you can send any commands to it and I find that to be a shortcoming.
I’m hoping in the near future the MIDI API will allow to apply actions to channels without the need for the intermediate step of selecting the channel (or track) first.

I don’t know if this is true for the midi assistant, but with scripting it definitely is not. You can always use a mixerBankZone and in this zone you can alter volume/pan as expected. What @bemi talks about is indeed the selected track’s volume.

Here’s a screenshot (so I have to assume that this also works with the midi assistant):

Inside each channel you can find its properties (volume, pan, etc) and bind them to your control.

1 Like

I notice the delay too. Especially when jumping around pages, and using mostly “Selected Track” assignments.

It depends very much on workflow. I don’t know how each one expects to use their controller, but for me it’s something like this:

  • Volume, pan → they get mixer bank zone treatment.
  • In the same page, EQ → Selected Track
  • On a second layer, plug-in control → Selected Track
  • On another page, virtual instrument control. → Selected Track
  • On yet another page, controls of sends 1-8 → Selected Track
  • On a web of pages, controls for Send 1 of Channel bank 1-8, Send 2, etc etc → Mixer Bank Zone.

Both assignment methods can be used simultaneously. It depends on what we want to do. But targeting a specific track, regardless of mixer bank or selection, I don’t think that’s possible without using Quick Controls. If anyone knows how, please, by all means, explain!

1 Like

It’s totally the MR , generic remote doesn’t suffer and right click ‘learn’ doesn’t suffer , CmC drivers don’t cause this , Novations don’t cause this ,Arturia don’t cause this BUT as soon as you apply any controller via the app it makes them useless for real time knob tweeting

Eh, I woudn’t call it useless. Once the page loads, it works fine. But when I change pages, I must press the button and then have a sip of coffee, before touching anything.

Strange, cause in my setup, pages’ changes happen in some 10’s ms. Perhaps you have a much more complicated setup :slight_smile:

If I understand you correctly, a way is to assign more than 8-16 tracks to your mixerBankZone. Say, 128 (which can be an overkill in many cases). This way you will have your tracks in an array (or map-object) and treat whichever you like from there.
In fact, in a previous attempt of mine on the fx plugin’s parameters bank zones, I used this workaround. Then I setup maps for my most used plugins inside the script (not by using the remote editor as you successfully do). I noticed delays, but after all, I’ve decided to abandon this way, because it would cost me a lot of time to remap, upon plugins’ (possible) updates.

1 Like

From a quick glance at what you have achieved, I wouldn’t dare call my setup complicated at all.

I’m talking about the total delay up to the point that motorized faders have flown to their correct positions for the parameter set under control, encoder leds show the correct parameter values, etc…

This is more pronounced when using my instrument page, which is an 84 parameter bank in essence, for Selected Track, Instrument

1 Like

I now understand better! My setup is using 16 params banks, so maybe this is why I get a faster update.
About motorized faders, I don’t have such device (apart from my panorama p6, but it’s just one motorized and I haven’t touched Nektar’s integration). Maybe I’ll buy one out of curiosity to test it. Can you suggest one?

1 Like