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, that build already delivers it.

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 from metering: it means analysing the music itself — where the beat is, how the tempo holds, where sections change, how energy moves — rather than reading its level.

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 on the music itself: a Pioneer deck read live over PRO DJ LINK (with the phrase analysis from the mounted rekordbox USB), or your own files played in Local Audio (DJ and Production editions), where each file is analysed for beat grid, phrases, energy, key and loudness. Where the beat comes from is 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 reads from the track 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 DJ's deck or a track playing from a file get bound to what the music is doing rather than to a stopwatch or an operator's reflexes.

Choosing Between Them

A short 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 a deck or a file with no timeline for QLab to chase, when the show includes a 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 a track it can read. CueSync reads a Pioneer deck over PRO DJ LINK, or a file you play in Local Audio; it does not pull a beat out of a microphone, a mixer feed or a live band, and for those a level follower or a tap-tempo beat is the right tool. Its experimental Booth Input listens to the room's energy and a bass, mid and high split to drive the LED pixel wall and any live link to Unreal Engine or TouchDesigner; the beat itself still comes from a deck, a tap, or the clock.

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