MIDI show control: QL, Companion and Lightkey

Does Program Change recall the next scene?

The QL5/QL1 V5.8 manual, pp. 188–190 assigns each Program Change to a specific event and destination. In PROGRAM CHANGE, select the SCENE event and its scene; do not interpret the message as a generic “next” command.

We propose testing two destinations in a copy of the show. Record port, channel, message sent, expected scene and recalled scene. Repeat from another starting point to check that the destination responds as intended. Record the result in the worksheet.

If the console recalls the correct scene but a setting does not change, continue with Focus and Recall Safe. Before preparing the test, also review the show backup.

The controller keeps old values after a recall: what should I check?

Check the model’s MIDI documentation to see whether it supports requesting values through SysEx and what response it returns.

The V5.8 manual, p. 192 identifies the MIDI channel as the device number for Parameter Change. Yamaha advises against simultaneous transmission/reception of Parameter Change and Control Change because of possible overflow. In the Data List, p. 39 (PDF page 318), PARAMETER REQUEST obtains the requested value as PARAMETER CHANGE.

We propose starting with one parameter in a copy of the show. Compare what the console displays with what the controller receives before and after recall. Save the message log and record whether the controller received the data, interpreted it or merely kept its previous indication. Do not infer a console fault solely from an encoder’s position.

The test worksheet is blank. If you work with files on the computer, separately check the Editor synchronization direction. This does not replace checking the controller’s messages.

One MIDI message triggers twice in Companion: what should I review?

If Companion executes an action when the arrival indicator changes from TRUE to FALSE, one reception can produce two triggers. The explanation does not include a final check by the affected user.

The Companion v4.3 guide, Triggers separates Events, Conditions and Actions: the event starts evaluation and conditions filter execution. This lets you check the trigger logic; it does not confirm that another module version uses the same names.

We propose testing in a copy: send one message, count executions and record both states. Check which condition allows the action through. Repeat with a message that should not act. Use the blank worksheet to compare expected and observed results.

If it still repeats, also review press and release actions. If the destination is a QL, then check the assigned scene. These are separate checks: counting executions and verifying what each command does.

Companion receives MIDI: how do I set up sending from a button?

Identify the device and versions, and check sent and received messages before using the control during the event.

The v4.3 guide, Actions distinguishes Press and Release: each group acts when pressing or releasing. The official Generic MIDI repository declares sending and receiving; its package.json identifies 2.1.1. The help lists MIDI Time Code as receive-only. Check the version available in your installation.

We propose starting with one button and one destination in a copy. Choose the send action offered by your module, record port, channel, message and value, and check what the destination receives. Review both button groups to see whether the command is repeated. Do not take a color change as proof that the message arrived.

Record the path in the worksheet. To update a QL controller’s indication after recall, continue with the parameter response.

The cue changes in Lightkey, but the button does not show it: what should I check?

The Lightkey and Companion versions are not reported, so identify that combination before testing.

The Lightkey Rev. 6.0 manual, p. 280 separates the path: commands from other applications arrive at Lightkey Input, and feedback from those mappings leaves through Lightkey Output. On pp. 286–287, None sends no feedback; Note On/Off reports activation and deactivation. Channel accepts 1–15: 16 is reserved for Live Triggers (p. 285).

The manufacturer’s help describes that path using a Stream Deck MIDI plug-in. Use it to check ports and messages; a Companion setup needs its own configuration. We propose activating and deactivating a cue from Lightkey, capturing feedback and comparing the cue, received data and button. Record releasing a key and deactivating a cue separately.

Save the test in the blank worksheet. To coordinate cues with the event, also review our lighting service. Check the function available in your version before changing the module.

MIDI arrives, but the button stays lit: what should I compare?

The Generic MIDI help stores noteStates by channel and note. Note Off, or Note On at zero velocity, sets that state to false. The module history introduces noteStates in 2.1.0 and documents the zero-velocity fix in 2.1.1.

According to Companion v4.3 Feedbacks, styling is applied in feedback order. We propose comparing three things in a copy: the received message, the state read by the condition and the final color. Record the active feedbacks and their order; a correct variable alone does not explain the display.

To test a note, compare Note On at positive velocity, Note Off and Note On at zero velocity in the version you will use. Do not extend what noteStates documents to all MIDI communication. If the source is Lightkey, review its feedback; record results in the worksheet.

The note only triggers at velocity 127: is the filter too strict?

The Companion v4.3 guide, Triggers defines conditions as filters on the event. Compare the incoming message with each condition: type, channel, note and velocity. Before writing a MIDI expression, check the lastMessage format and instance name in the installed version.

We propose repeating the same note at two different positive velocities and recording whether the condition and action respond. Then test another note and another channel that should be excluded. If you need a velocity threshold, define it deliberately: do not remove it just to make any strike trigger.

Record the test and separately review duplicate triggers. An accepted note and a single execution are separate checks. This section reviews the input filter; it does not propose an ATEM or controller configuration.

The Macs appear connected over MIDI, but nothing arrives: where should I start?

The Apple guide for Audio MIDI Setup 3.6, macOS 26 explains how to create and enable a session, allow connection and use Connect. The other device must appear among connected participants. Control names depend on the version: compare them with your macOS manual. Seeing a participant and receiving a message are separate checks.

In Lightkey help, choose the network session as Input and as the destination in the sending application.

We propose following one command from A to B: first its MIDI output, then reception at B and finally the assigned action. If using a USB controller, also record who routes it to the session. A monitor is for observation; receiving a message there does not demonstrate that the destination application uses it.

Save ports and messages in the test worksheet. Before the show, repeat the test after a planned reconnection and count executions. If the command arrives but the button does not change, follow the feedback. To coordinate control with the setup, ask about our lighting service.

The command arrives over the network, but the button gets no feedback: what should I review?

The control did work over direct USB. Keep the sending result separate from the feedback result.

The Lightkey Rev. 6.0 manual, p. 300 allows enabling inputs and outputs in Settings > External Control. To associate them: Control-click the input, Send Feedback To and the selected output.

We propose drawing the full return path: Lightkey on B → session B MIDI output → session A input → destination application or controller. Capture a cue change generated from Lightkey and look for the message at each stage. Reaching Mac A still leaves the route to the controller and the condition that renders the button to check.

Record the outgoing command and returning state separately. Do not forward every input to every output without deciding which path you need: the test must check that one command produces the intended number of actions. Also review feedback and cue state and note off and color.

The Ableton help, applicable to all versions, distinguishes MIDI transport from synchronization and recommends Link to synchronize compatible applications. If you only need shared tempo, evaluate that goal separately. A synchronization test does not resolve button feedback.

Record both directions and repeat them after reconnecting, using the blank worksheet. The proposed reconnection does not guarantee recovery of the button’s previous state: compare its indication with the actual cue before continuing.

Link keeps the tempo, but each application shows a different bar: what else needs checking?

Distinguish tempo synchronization, transport and position when evaluating Ableton Link.

The Live 12 manual, sections 37.1.1–37.1.2 documents Start Stop Sync for participants that have it enabled. It also explains that starting waits for launch quantization and any participant can change tempo. Decide who will change BPM during the show.

The Ableton FAQ, Start Stop Sync explains that Live starts according to its local time, quantization and start marker. Sharing tempo and start is not enough to check the point within a song or the cue that should be active.

We propose recording four items per application: BPM, transport, position and intended cue or action. Start from a reference chosen for the test and compare those items before introducing changes. After reconnecting, check position and state again; seeing another participant in Link is not the complete result of that test.

To trigger a specific action, also follow the MIDI path and the feedback to the button. Save observations in the blank worksheet. You can coordinate actions with our lighting service.

MIDI reaches Lightkey, but Live Triggers are missing on another computer: what should I review?

Check versions, transferred files and triggers on both computers before considering the handoff ready.

The Lightkey Rev. 6.0 manual, pp. 292–293 places preparation on the same computer: Enable Live Triggers in External Control and clips under User Library > Lightkey. Do not take a MIDI connection as proof that those clips are available in the destination library.

The Lightkey help, receiving from another computer distinguishes preparation from execution: both applications must be on the same Mac when creating Live Triggers; they can then run on separate computers.

We propose first checking one clip and its action in a copy of the prepared setup. Record the project, page and cue corresponding to that clip. Before testing from the other computer, check that the clip is available there and review its MIDI destination. Record the received message and observed action; copying a file still leaves that test pending.

Keep the set and project you will test, and record their versions in the worksheet. If the clip is present but does not respond, follow MIDI output and reception; if it responds but the indicator differs, review the feedback.

The clip or cue starts late: should I check quantization, start or reception?

Compare those stages separately before changing the show.

The Live 11 manual, 14.1 and 14.4 limits launch settings to Session View: Arrangement plays according to clip positions. In Session, Global uses global quantization and None disables it. We propose comparing one clip in a copy with None only if that entrance does not need to wait for the musical grid; record the previous setting so you can restore it.

The Lightkey Rev. 6.0 manual, pp. 294–295 says to adjust duration using the right edge. Moving the left edge can delay or remove the initial message. To repair it, double-click the clip and move Start Marker to the far left of the MIDI Note Editor.

Before changing several settings, we propose recording when you requested launch, when the clip started and when the cue changed. Compare a trigger from stopped transport with one during playback. If you cannot measure the difference, leave it as an observation and attach a screenshot; do not fill in estimated milliseconds.

To log reception and effect, External Control Log, p. 315, must be open and unpaused. Add the log to the worksheet and follow the MIDI route.

I stop the song and the light stays on: which state do I need to release?

We propose testing two situations separately: letting the clip finish and stopping the song early. First choose which scene should remain in each case: a pause may need work light or a standby scene. Record the object you control and where you activated it from.

The Lightkey Rev. 6.0 manual, pp. 293–294 and 215–216 distinguishes Live Triggers: a button cue lasts as long as its clip; in a cuelist it remains until another is activated. Outside that control, cues generally remain until deactivated, with exceptions depending on their configuration.

The actions, pp. 288–289 separate Deactivate All Cues from Deactivate All Presets. Active presets take priority over cues (pp. 127–128). Also review overridden properties and fixture output.

In a copy of the project, we propose testing the action appropriate to the object and recording its effect. Compare natural completion, early stop and restart. Do not assign a global release to the transport button until you have reviewed which other scenes would be affected and tested the standby scene.

Save observations in the blank worksheet. If the command arrives but the indicator does not match the action, review controller feedback. To prepare show entrances and pauses, you can coordinate the setup with our lighting service.