Show control: when cues should be linked and when they should not

By Joey Calkins · Section Rehearsal

Show control means one system telling another to do something. A lighting console fires a sound cue, a video server advances a projection, a timecode stream drives all of them. The technology is unremarkable. The question worth thinking about is what each link removes, because every link removes a person from a decision.

What linking actually buys

Simultaneity is the honest answer. Where a light change, a sound and a video hit must land together, human reaction time is a variable of tens of milliseconds spread across three operators, and the effect either lands or it does not. A single trigger removes that spread entirely.

Linking also removes parallel workload. Calling four cues in the same half second is difficult, and a caller doing it is not watching the stage. Collapsing them into one call is a real gain in attention, which is the scarcest thing in the corner.

What it costs, in one sentence

A linked cue happens whether or not it should.

An operator who sees an actor still crossing waits. A trigger does not. Everything that made a human worth having in the chain, the judgement about whether the moment has actually arrived, is exactly what the link discards, and that judgement is only worthless when the timing is genuinely fixed.

The distinction that decides each case

Some cues are fixed to each other. A gunshot and the light that goes with it are one event, and their relationship does not depend on anything happening in the room. Those belong linked.

Some cues are fixed to the performance. A blackout on the last word, a sound that starts when a door closes, a change that follows an audience's laugh. Those are responses, and they belong with a person who is watching.

Most productions get this mostly right by instinct and then link a handful of the second kind because it was convenient during programming. Those are the cues that go wrong on the night an actor drops a line.

Chains propagate faults

A trigger that fans out from a single called cue keeps a person at the moment of decision, and the systems downstream simply obey. A chain in which each cue triggers the next has nobody in the loop after the first one, and it will continue through a problem rather than pausing at it.

Two consequences follow. A wrong trigger becomes several wrong outcomes rather than one, and the sequence needs a way to be stopped that somebody in the building has practised. An abort that exists in a manual and has never been used is not an abort.

Nobody owns a fault that crosses a boundary

The characteristic pathology of linked systems is diagnostic rather than technical. Sound reports that no message arrived; lighting reports that it was sent; both are telling the truth, and the problem is somewhere in between, in a network nobody in the room administers.

The practical mitigations are ordinary. Show traffic belongs on its own network rather than sharing with the building's general use, so that a large file transfer in an office cannot affect a cue. Every triggering relationship belongs written down in the book alongside the cue it serves, so that a caller can see what one call will actually do. And the system that fires cues should report what it fired, somewhere the caller can see it, because a link that operates invisibly removes the caller's picture of the show as well as their decision.

Programming order decides who can rehearse

There is a scheduling consequence that is easy to miss. Once cues are linked, the department that owns the trigger controls when the others can work. A sound operator whose cues fire from the lighting console cannot test anything while lighting is plotting, and a video department waiting on a timecode source cannot check a transition without somebody else running the clock.

On a short technical schedule this quietly serialises work that could have happened in parallel. Keeping a local manual trigger on every system, alongside the linked one, restores the ability to work independently and costs nothing but the discipline of remembering which mode a system is in when the run begins.

Timecode is the strongest form of this

Running everything from a clock is show control taken to its limit, with the same properties in stronger form: perfect internal synchronisation, and no capacity to respond. The article on click tracks covers the musical version of the argument, and it applies here unchanged.

What we cannot verify

The protocols involved are published specifications, but reliability and latency in a specific installation depend on the network, the equipment and the load, and figures quoted by manufacturers are measured under conditions they do not describe. We reproduce none of them. Practice differs greatly between houses and between scales of production, and what is described here is common practice rather than a standard.