Audio-Reactive Cues Over OSC: What QLab Can and Cannot Do

The Build Everyone Arrives At

Search for audio-reactive lighting in a theatre context and the same architecture comes back every time, usually assembled from forum posts: a QLab network cue queries an audio cue for its current output levels over OSC, the reply is mapped onto a dashboard level or a lighting parameter, the query repeats on a loop, and something on stage starts moving with the sound.

It is a good technique. It uses tools already in the rack, adds no hardware, and an operator who understands QLab can maintain it. If what you want is a look that breathes with the show, stop reading — you already have the answer, and adding a product to it would make your rig worse.

This post is about the ceiling that build has, because a great many people hit it and conclude that audio-reactive lighting simply does not work well, when what actually happened is that they measured the wrong thing.

Amplitude Is Not Structure

Every level-query approach shares one property: it reads amplitude. How loud is this, right now.

Amplitude is a genuine and useful measurement. It is also almost entirely uninformative about the questions a cue actually wants answered:

• Where is the beat? Not recoverable from loudness. A track can be at identical level across the whole bar.
• Did the section change? A chorus is not reliably louder than the verse before it, and the transition that matters is often the last beat of the build — a moment defined by what stops, not by what gets louder.
• Has the energy stepped up? Energy and level part company constantly. A sparse, tense, quiet passage can carry more energy than a loud one.
• What key are we in? Not present in an amplitude reading at all.

This is why level-driven rigs feel convincing in rehearsal and disappointing in performance. Loud moments and important moments overlap often enough to look right in a demo, and then the show reaches a quiet climax and the lighting does nothing, because nothing got louder.

The fix is not a better mapping curve, a smarter smoothing filter, or a faster poll. There is no function of loudness that recovers musical structure, because the structure was never in the loudness.

What Structural Analysis Adds

Extracting structure is a different class of work: onset detection to find beats, tempo tracking to hold a grid across tempo drift, spectral analysis to locate section boundaries, and a model of energy that is not simply a level meter with a longer window.

Once that exists, a cue can be bound to a musical fact rather than to a threshold:

• On the beat, or on a specific beat of the bar, which is what makes a hit read as intentional rather than approximate.
• On a phrase boundary — the moment the section changes, which is where the lighting change belongs and where a level follower is silent.
• On an energy transition, a step change in intensity independent of volume.
• On a key change, for rigs that map colour to key.

CueSync's engine does this against live audio in real time, without a pre-analysed file. The mechanics are covered in how CueSync detects beats.

Keep Your Rig; Add a Layer

The reason this does not have to mean replacing anything is that the output of analysis is just messages.

CueSync publishes what it hears as ordinary show-control traffic: OSC to anything that accepts OSC, native command vocabularies for GrandMA2 and GrandMA3, ETC Eos, ChamSys MagicQ and Avolites Titan, MIDI Show Control, and QLab over TCP with an OSC fallback. Nothing in an existing QLab-based show has to be re-authored to receive it. QLab keeps running the scripted cues; the reactive cues arrive as network events the way any other trigger would.

That division tends to match how shows are actually built. The scripted spine — the parts that are the same every night — stays where it already is. The parts that follow a live band, a DJ, or an improvised passage get bound to what the music is doing rather than to a stopwatch or an operator's reflexes.

Choosing Between Them

A short and honest decision procedure:

Use a level follower when the effect should track loudness, when the audio comes from a file you already play in QLab, when the rig must be maintainable by someone who has never heard of onset detection, or when "close enough" is genuinely close enough. This covers more real theatre work than automation marketing suggests.

Use structural analysis when cues must land on musical events, when the source is live and has no timeline to chase, when the show includes a band or DJ who will not play it the same way twice, or when a quiet moment needs to trigger something.

Use both when the show has both kinds of moment, which is most shows of any size. They do not conflict; they are different sensors reporting to the same cue stack.

What This Does Not Solve

Two limits worth stating plainly.

Analysis needs the audio. If the only feed available is a room mic in a loud venue, expect degraded results — bleed, reflections and PA colouration all corrupt the analysis, and no amount of processing fully recovers it. A clean feed from the desk is worth more than any algorithm choice.

And analysis is not intent. Knowing that a phrase boundary just passed does not tell anyone what should happen there. That is a design decision, made by a person, in advance. Automation fires the cue; it does not write it.

Further Reading

• CueSync for Theatre Operators — cue stacks, Show Editor, Run Mode
• How to Send Timecode to GrandMA3 — the scripted counterpart to this reactive workflow
• QLab integration — TCP addressing with OSC fallback
• CueSync vs QLab for DJ Shows — where the two tools divide a hybrid show