MIDI Remote direct SendSlot.mLevel control causes noticeable lag

Cubase
, ,
1

System:

  • Cubase Pro 15.0.30 Build 287 (x64)
  • Windows
  • Novation Launchkey Mini MK4 37
  • MIDI Remote API script based on the Novation Launchkey MK4 script

Description:

Direct control of send levels through the MIDI Remote API causes noticeable lag and stuttering. The same sends can be controlled smoothly when they are triggered through Cubase macros and Quick Controls, so the problem appears to be specific to direct MIDI Remote bindings to SendSlot.mLevel.

Steps to reproduce:

  1. Connect a Novation Launchkey Mini MK4 37 and activate its MIDI Remote script.

  2. Create or open a project containing a channel with several configured sends.

  3. In the MIDI Remote script, bind the eight encoders to Sends 1–8 of the selected channel using:

    page.mHostAccess.mTrackSelection.mMixerChannel.mSends.getByIndex(index).mLevel

  4. Activate the Sends encoder mode on the Launchkey.

  5. Turn one or more encoders to change the send levels.

  6. Also press Shift on the Launchkey while using this configuration.

Actual result:

The send controls react with noticeable lag or stuttering. Even pressing Shift can feel delayed while the direct send bindings are in use.

Expected result:

Send levels and other Launchkey controls should react immediately and smoothly, comparable to Track Quick Controls.

Comparison tests:

  • The same physical Launchkey encoders control Track Quick Controls smoothly.
  • The sends react smoothly when controlled through Cubase macros assigned through Quick Controls.
  • The PO16 controller also triggers send-related Cubase macros smoothly.
  • Direct control of send levels was not implemented or tested on the PO16.
  • Changing the MIDI Remote value takeover mode did not solve the delay.
  • Reducing unrelated background scanning in the custom Launchkey script did not solve the direct send-control delay.

This suggests that the delay occurs specifically in the MIDI Remote path for direct SendSlot.mLevel bindings rather than in the project, the sends themselves, or the MIDI hardware.

This report was prepared by an AI assistant acting on behalf of forum user Flowshi.

2

Please mark as solved.

Update: direct send control now works smoothly in my current setup.

During further testing with Intech GRID controllers (PO16, EN16 and BU16), I reproduced similar lag, including send controls continuing to move after I had stopped turning an encoder.

In this setup, MIDI feedback handling turned out to be the main factor. Monitoring the traffic showed that moving a single control could generate entire blocks of redundant feedback messages for other controls.

The working solution was to:

  • Keep native MIDI Remote bindings for controlling the parameters, including SendSlot.mLevel.

  • Disable automatic MIDI output on the physical surface bindings.

  • Use separate, input-free custom value variables bound to the host parameters for LED feedback.

  • Cache the last transmitted LED values and send only changed, quantized values for the affected control.

  • Avoid global DirectAccess parameter monitoring and repeated channel searches during encoder movements.

On the GRID side, local automatic LED intensity updates were also disabled so they would not overwrite the host feedback.

All eight sends now respond smoothly, including fast encoder movements, with working LED feedback and push-to-toggle send on/off.

Therefore, my original conclusion that SendSlot.mLevel itself was necessarily responsible was too strong. Direct send bindings can work smoothly; feedback handling needs to be checked carefully.

This confirms the solution for my current GRID setup. I have not yet verified the same changes on the original Launchkey script.