Show Control Fundamentals

Introduction

One press, and four departments move at once: the lights change, the video starts, the sound stings, the scenery flies. Show control is the wiring between the systems that makes that press possible, and the discipline that makes it happen the same way tomorrow night.

It is not a craft of its own so much as the join between crafts. Everybody on a show owns a system; show control owns what they say to each other, what clock they follow, and what happens when one of them stops answering.

What this book covers

• What show control is, why productions use it, and what a cue actually is.
• Cue lists, numbering, and the difference between calling a show and running the machine.
• Triggering: central controllers, peer-to-peer links, and who commands whom.
• The protocols — MIDI and MIDI Show Control, OSC, DMX and its network versions, contact closures, serial and device APIs.
• Timecode: LTC and MTC, frame rates, drop frame, distribution and jam sync.

• Triggered shows against timed shows, and who owns the master clock.
• Designing a control plan, and documenting it so somebody else can maintain it.
• Networks for control: isolation, addressing and reliability.
• Testing cues cold, error handling, logging and manual fallbacks.
• Interlocks, permissives and the systems a show controller must never fire.

Who this is for

Technicians who already run one system and are being asked to connect it to the others: lighting programmers driving servers, video operators following timecode, audio engineers firing cues, and anybody moving toward integration or show-control design. It assumes Networking Basics and a working knowledge of at least one show department.

How to Use This Book

Read it once through, then build something small. The chapters follow the work: what a cue is, how systems are linked, what they say to each other, what clock they follow, how it is designed, and what happens when it breaks.

Build a two-system rig

Almost everything here can be practised with two machines on a desk: a laptop sending OSC to another, a MIDI interface firing a media player, a lighting desk driving a server over Art-Net. Making two systems talk teaches more in an afternoon than any amount of reading about protocols.

Keep a notebook

Write down every cue number and what it triggers, the protocol and address each system listens on, what each department expects to receive and what it sends back, and the manual fallback for anything that would stop the show. Show control fails quietly and at speed, and the notebook is what lets somebody else take the seat.

A note on the words

The vocabulary overlaps confusingly. A cue is a moment, a list entry and an instruction depending on who is speaking; trigger, command and message are used interchangeably; sync means genlock to one department and timecode to another. This book uses the words most widely understood and names the alternatives where they matter.

A note on safety

Show control touches systems that move scenery, fire pyrotechnics and project lasers, and those systems have safety regimes that exist independently of any controller. Nothing here qualifies you to design an interlock, operate automation, or fire an effect. It teaches you the line between control and safety, why that line exists, and why it is never crossed for convenience.

Where this book sits

This book assumes Networking Basics and a working knowledge of at least one show department. It does not assume you have ever connected two systems together.

What pairs with this

• Networking Basics — the network every modern trigger travels on
• AV Documentation & System Design Basics — the drawing discipline a control plan belongs to

Where it leads

These are not steps in an order. Take whichever one fits.

• Integration Project Management — running the projects these systems are built inside
• Media Servers 101 — the playback system your cues will be driving
• Lighting Operation — the desk at the other end of half these triggers

What Show Control Is

A show is several independent systems that have to agree about time. Show control is how they agree: what tells what to do, when, in what language, and what happens when one of them is not listening.

Show control is the conductor that makes every department play the same beat.

One show, many systems

A modern production has many independent systems — lighting consoles, media servers, audio, automation, special effects — each capable of running on its own. Show control is the layer that coordinates them so they act as one: at a single command, lighting changes, video rolls, audio fires, and a set piece moves, all together and precisely on time. Without show control, hitting a complex multi-system moment relies on several operators each trying to react simultaneously; with it, one cue fires everything in perfect sync. Show control is the conductor that makes the whole production move as one.

This is why show control is integration work: it sits above the individual systems, tying them together. It does not replace the lighting console or the media server — it triggers them. Understanding show control means thinking about the whole show as an integrated system, which is a step up from operating any single discipline and an increasingly essential capability as productions grow more complex and automated.

Lighting, video, audio, automation, effects, house systems and often the building itself each run on their own machine, programmed by their own person. Left alone they are four shows happening in the same room at roughly the same time.

Show control makes them one show. It does not replace any department's programming; it decides what starts it, and makes sure the four things that must happen together actually do.

Why productions use it

Show control delivers two things productions prize: precision and reliability. Precision because a programmed cue fires every system at exactly the right instant, every time, removing the human timing error of operators trying to hit a moment together — a choreographed sequence lands perfectly on every show. Reliability and repeatability because once a show is programmed, it runs the same way each time, which is invaluable for repeated performances, complex sequences, and shows that must be flawless. A themed attraction, a touring concert, a polished corporate show — all lean on show control to deliver consistent, precise, complex moments.

It also reduces the crew needed to run complex moments and frees operators to focus on the parts that need live human judgment while the controller handles the precisely-timed sequences. The trade is that the work moves earlier — into careful programming and rehearsal — so the live show is reliable execution. This front-loading of effort into programming, for precise and repeatable results, is the essence of show control.

Three reasons, in order of how often they are the real one. Precision: some moments are too fast or too complex for four people to hit together. Repeatability: the show must be identical every night, for months. People: a system that runs itself needs fewer operators, which is sometimes a budget and sometimes the only way an install can exist at all.

It is worth knowing which reason applies to the show in front of you, because it decides how much complexity is justified. Precision buys automation; convenience rarely does.

What show control is not

It is not a safety system. A show controller may ask an automation system to move a piece of scenery, but the interlocks that stop it crushing somebody are separate, and they are not in the show controller.

It is also not a substitute for department programming. A perfect control plan firing a badly programmed lighting cue produces a badly programmed lighting cue, on time.

Where you meet it

• Theatre: a stage manager calling cues that fire several systems at once.
• Concerts: songs locked to timecode, with the talking bits called by hand.
• Corporate: a run of show driving lighting, video, audio and staging.
• Attractions and museums: unattended shows running on a schedule for years.
• Broadcast: playout and studio systems interlocked with the gallery.
• Worship and education: volunteers running complex systems with one press.

Why a production reaches for show control

The reason decides how much complexity is worth building.

On the job

A product launch has a moment where the logo hits the wall, a spotlight snaps on, a sting plays and a curtain drops. Four operators rehearsing it get within about a third of a second of each other, which looks like a mistake. One timecode-locked sequence hits it identically, eleven times a day, for a week.

What goes wrong

Practice it

Take any show you have worked on.

Cues & Sequencing

A cue is the unit everything else is built from: one identifiable moment, with a number, that causes something to happen. Get the cue list right and the show is a conversation; get it vague and every department is guessing.

A show becomes a list of cues — moments programmed to fire on command.

What a cue is

In show control, a cue is a programmed action or set of actions that fires on command — the same cue concept you met in lighting, media servers, and playback, now extended across all systems. A single show-control cue can tell the lighting to change, the media server to play content, the audio to fire a sound, and a motor to move, all at once. The operator (or the system) triggers the cue, and everything in it happens together. Cues are the building blocks of a controlled show: each programmed moment is a cue.

Cues are built in advance, during programming, so that each moment of the show is captured as a cue ready to fire. This is the same prepare-then-execute pattern seen throughout AV work — the careful work happens before the show, so the live show is triggering prepared cues. A cue bundles a precise moment across many systems into one fireable unit, which is what makes coordinated complexity manageable.

In show control a cue is an instruction with a name: at this moment, send these commands to these systems. It may fire one device or twenty, and it may be triggered by a person, a clock or another machine.

What makes it a cue rather than an action is that it is identified. It has a number, it can be referred to in a room full of people, and it can be fired again tomorrow in exactly the same way.

The cue list and sequencing

A show is sequenced as a cue list — the ordered series of cues that make up the production, from start to finish. Running the show means advancing through the cue list, firing each cue at its moment, usually with a single GO command. As each cue fires, all its systems respond together; the operator (or show caller) simply progresses through the list. This is exactly the cue-list discipline from lighting and playback, raised to coordinate the entire show. The cue list is the show, written as a sequence of synchronised moments.

Sequencing the whole show this way is powerful: complex productions with hundreds of precisely-timed multi-system moments become a manageable, repeatable list that runs reliably on GO. It also makes the show callable — a show caller can call cue numbers, and everyone (including the show control system) knows exactly where they are. The cue list turns a sprawling, multi-department production into one coherent, ordered, runnable sequence.

The cue list is the show in order. Number whole moments with whole numbers and use decimals for whatever rehearsal adds, so that the list can grow without renumbering anything that other departments have already written down.

Every cue gets a name that means something out loud: "12 — house to half" rather than "12". The name is what gets said on comms at speed, and vague names produce hesitation exactly when there is no time for it.

Cue numbers are a shared interface

Once a lighting desk, a server, a sound rig and a stage manager's book all refer to cue 47, that number belongs to the production rather than to you. Renumbering it is an interface change, and it has to be announced.

This is the commonest avoidable failure in show control: somebody tidies the numbering, everybody else's paperwork stops matching, and the next rehearsal is spent finding out why.

Who calls the show, and who runs the machine

In theatre and most corporate work, the caller — usually the stage manager — decides when a cue happens and says so; the operator executes. The two jobs are separate on purpose, and the operator never anticipates.

In concert and installed work the roles collapse: the operator is also the caller, or there is nobody and the clock decides. Knowing which arrangement you are in tells you who is allowed to make a decision at eight o'clock.

Grouping and dependencies

Some cues must happen together, some must happen in order, and some must not happen at all if an earlier one did not. Write those relationships down before building them, because they are what turns a list into a sequence.

Beware chains: a cue that fires a cue that fires a cue is elegant until one link fails silently, and then nobody can say where the show stopped. Prefer one controller firing several systems to a chain of systems firing each other.

What every cue in a list should carry

A cue list is read by other departments. Write it for them.

How to do it

1. Start from the show's actual moments, not from the systems.
2. Number whole moments with whole numbers, leaving room between them.
3. Name each one in the words people will say on comms.
4. Say for each what triggers it and what it targets.
5. Mark the cues that must happen together and those that depend on others.
6. Circulate the list to every department that refers to a number.
7. Re-issue it after any change, with the change marked.
8. Never renumber without telling everybody first.

What goes wrong

Practice it

Take a show you know and write its first ten cues.

What Show Control Does in Each Department

Show control is not one subject. It is the join between six or seven departments, each with its own system, its own operator and its own idea of what a cue is. What you can ask of each of them, and what you must never ask, is the working knowledge this job is built on.

Lighting

The department most often driven, and the one most able to drive others. A lighting console holds a cue stack of its own, so show control usually fires its cues rather than setting its levels: a go, a jump to a cue number, or a macro. That keeps the lighting programmer in charge of what the cue actually does.

It goes the other way too. A lighting console can drive media servers over DMX or its network equivalent, fire audio, and send its own triggers out. On concerts the lighting operator is frequently the show controller in practice, busking video and lighting from one surface.

What not to ask: do not take over a console's levels mid-show unless everybody has agreed, and do not renumber its cues. That stack is somebody's work and somebody else's paperwork.

Video and media servers

The department that most often needs frame accuracy, and therefore the one most often locked to timecode rather than fired by a trigger. A media server takes cues, timecode, or direct control of its layers; a video switcher takes macro or salvo recalls and simple contact closures.

The distinction that matters: firing a video cue starts something with a duration, and the show may need it to land on a frame rather than merely start near one. If it must be exact, put it on the clock instead of on a trigger, and measure the chain's latency so the trigger can be offset.

What not to ask: do not reorder a server's clip list without telling its operator, because on many shows that list is the interface a lighting desk is already addressing.

Audio

Audio arrives in three parts and each is controlled differently. A mixing console recalls snapshots or scenes, usually over MIDI or the console's own network protocol. Playback — music, effects, stings — runs on a cue system that show control can fire directly. Processing — the DSP in an installed venue — recalls presets that change routing, levels and the whole behaviour of a room.

In theatre the audio department often is the show control system: a cue system on a laptop that plays sound, fires lighting over MSC and triggers video, all from one list called by the stage manager.

What not to ask: never fire an audio cue that could be loud without the operator knowing. A recalled snapshot that unmutes a channel into a full PA is a hearing risk, not just an embarrassment.

Automation and scenery

The highest-consequence thing a controller ever talks to, and the one with the firmest rule: show control may request a move and may tell an operator that a moment has arrived, but the move itself happens under a permissive held by a trained person watching the stage.

In practice this means a controller sends a standby, lights a lamp on an automation desk, or arms a sequence; the automation operator presses and holds. Anything that removes that person from the loop is outside this book and outside the trade's practice.

Pyrotechnics, flame and lasers

Pyrotechnics, flame, lasers, water, wind, snow and confetti. Each has its own licensing, its own operator and its own arming. The controller's legitimate role is timing information: a standby, a cue light, a countdown the licensed operator acts on.

Lasers deserve a specific note: they are enabled by a trained operator, interlocked to zones and to emergency stops, and nothing about that changes because a cue would be tidier.

The building itself

House lights, drapes, doors, lifts, blinds, projection screens, heating and ventilation — in installed venues all of these can be under control, and on many corporate shows the house lights fading with the first video cue is the moment the audience notices somebody is in charge.

Building systems are usually reached through a room control platform or a building management system rather than directly, and they are slow: a drape takes seconds, a screen takes longer, and a cue that assumes they are instant will look broken.

Broadcast and studio systems

A gallery is show control by another name: automation systems recall router salvos, fire playout, move robotic cameras, change graphics and drive tally, all against a rundown rather than a cue list.

The vocabulary differs and the principles do not — a shared clock, a sequence of moments, systems that must be told what to do, and a fallback for when one of them does not answer.

What each department accepts, and what it will not give you

Ask for the first column; never ask for the last.

On the job

A corporate opening fires five departments on one cue: house lights to a preset, a video sting on the clock, a lighting state, an audio playback, and a standby lamp on the automation desk for a reveal the operator will perform. Four are automated, one is a person, and the difference is deliberate.

What goes wrong

Practice it

Take one show you know with several departments in it.

Triggering & Protocols

Triggering is one machine telling another to do something. Protocols are the languages they use. Most of the technical work in show control is deciding who speaks to whom, in what language, over what wire — and then proving that the message actually arrives.

For one cue to fire many systems, those systems must speak a common language.

Triggering across systems

The heart of show control is triggering — one system sending a signal that makes another system do something. When a show-control cue fires, the controller sends trigger messages to each system (play this content, run this lighting cue, fire this sound), and each responds. This requires the systems to be connected and to understand the triggers, which is where control protocols come in: the shared languages that let one system command another. Triggering is the mechanism; protocols are the language.

Triggering can flow in many ways — a show controller firing everything, or one system triggering another directly (a lighting console triggering the media server, say). The key idea is that systems are linked so an action in one causes an action in another. Setting up this web of triggers correctly — so the right command reaches the right system and produces the right response — is the core technical work of show control.

The pattern is always the same: a source decides a moment has arrived and sends a message; a target receives it and does something. Everything else — protocol, cabling, topology — is detail about how that message travels.

Ask three questions of every link. What sends it? What receives it? And how would you know it arrived? The third question is the one people skip, and it is the one that matters at eight o'clock.

The common protocols

A handful of protocols carry most show-control communication, and recognising them is essential. MIDI and OSC are common messaging protocols for sending trigger commands between systems (originally from music, now widely used to trigger show systems). DMX (from lighting) carries lighting control and is sometimes used to trigger or be triggered. Network protocols carry triggers and data over standard networks, increasingly the backbone as systems become networked. And timecode is a shared master clock that systems lock to for synchronised playback. Each has its place; together they are how show systems talk.

You do not need to master each protocol's technical detail at this level — you need to recognise them and understand that they are the languages systems use to trigger and synchronise. Matching the right protocol to connect two systems (what does each speak, how do they link) is the practical skill. As with networking, the AV professional who understands these control languages can integrate systems that others see as incompatible black boxes.

MIDI carries notes, program changes and MIDI Show Control commands. OSC carries addressed messages over a network. DMX, Art-Net and sACN carry lighting control and are routinely used as triggers. Contact closures and GPIO carry the simplest possible message: something happened. Serial links control older and installed devices. Network APIs cover everything modern that listens on a port.

Timecode is the odd one out: it is not a trigger but a clock, and systems following it decide for themselves what to do at each moment.

Central, peer to peer, and chains

In a central topology one controller fires everything, and one place holds the truth about the show. In peer to peer, systems trigger each other directly — a lighting desk firing the server — which is simple and spreads the truth across several machines.

Chains, where A fires B which fires C, are the fragile case: a break in the middle stops everything downstream and gives no clue where. Prefer one controller firing several targets, and keep chains short where they are unavoidable.

How a message actually travels

Underneath every network protocol in this chapter are two ways of sending something, and the difference decides whether you ever find out that a trigger failed.

TCP is a conversation: the sender opens a connection, the receiver acknowledges what arrives, and lost pieces are sent again. If the far end is not there, the sender is told. It costs a little time and a connection that has to be maintained, and it gives you something precious — the knowledge that your message landed.

UDP is a postcard: the message is sent to an address and a port, and nothing comes back. No acknowledgement, no retry, no error. It is fast, it is simple, it suits a stream of values where the next one is along in a moment — and it is why an OSC cue that never arrives produces silence rather than a warning.

Most show-control messaging is UDP, including OSC as it is usually configured, and the lighting network protocols. That is not a flaw; it is a design choice for traffic that is frequent and time-sensitive. But it means the burden of knowing falls on you: monitor the traffic, use a protocol that replies where one exists, or make the target send something back.

Two more words you will meet. A port is a number the receiving device listens on, and a message sent to the right address on the wrong port disappears exactly as if the cable were unplugged. And a message is sent to one device (unicast), to a group that asked for it (multicast), or to everybody on the network (broadcast) — which is fine for a handful of messages and a bad idea for a stream.

MIDI and MIDI Show Control

The simplest MIDI trigger is a note: press a key, something happens. MIDI Show Control is a defined command set on top of MIDI — go, stop, resume, with a cue number and a device number — designed for exactly this job and still standard in theatre.

Its strengths are that it is old, defined, universally implemented and runs on cheap hardware. Its weaknesses are cable length, the need for interfaces, and that it tells you nothing about whether anything happened.

OSC

An OSC message is an address and some arguments, sent over a network: a path such as a slash-separated name, plus values. It is readable, flexible, easy to test, and supported by most modern show software.

Its weaknesses are the network's weaknesses. Messages are usually sent without acknowledgement, so a message that never arrives produces silence, not an error — which is why testing with something that echoes back matters.

Contact closures, serial and APIs

A contact closure is two wires touching: no addressing, no configuration, nothing to go out of date. It is the most reliable trigger in the industry and still the right answer for a button, an emergency signal or a link between two systems that share nothing else.

Serial control — the connector marked RS-232, and its longer-distance relative RS-422 — survives in projectors, screens, switchers and a great deal of installed equipment. Network APIs are where new equipment lives: a message to a port, usually over TCP, often with a reply — which is the useful difference — a protocol that answers lets you know the command arrived.

Protocols, and what each is good and bad at

Choose by what both ends speak, and by whether you need to know it arrived.

How to do it

1. Find out what each end actually supports, from its documentation.
2. Choose the simplest protocol both ends speak.
3. Connect them on the shortest, most direct path you can.
4. Send one message by hand and watch for the response.
5. Use a monitoring tool to see the traffic, rather than guessing.
6. Make the target show that it received the message, not just act.
7. Write down addresses, ports, device numbers and cable routes.
8. Test it cold the next day, before trusting it.

What goes wrong

Practice it

With two machines on a desk.

Timecode & Synchronization

Timecode is not a trigger. It is a clock, broadcast to everybody, where each department decides for itself what to do at each moment. That difference is what makes it the most precise tool in show control, and the one that fails in the most confusing ways.

For moments that must be perfect every time, systems lock to a common clock.

Timecode and locked playback

Timecode is a master timing signal — a continuous clock — that multiple systems lock to so they all play in perfect synchronisation. When a sequence must be frame-accurate every single time (a complex show piece where lighting, video, and audio are choreographed to hit exact moments), the systems are run to timecode: each follows the same clock, so everything lands together automatically, removing human timing error entirely. Timecode-locked playback is how the most tightly choreographed show moments are achieved with perfect repeatability.

This connects to the synchronisation ideas from the intermediate books: media servers, audio, and lighting can all be slaved to timecode so a programmed sequence runs identically on every show. Timecode is the tool for sequences too precise or complex for manual triggering. Understanding that systems can run either by triggered cues (fired on command) or locked to timecode (following a clock) — and when each is appropriate — is key show-control knowledge.

A generator produces a continuous count — hours, minutes, seconds, frames — and distributes it. Each system holds a list of what it should do at which times and follows the clock. Nothing is sent to anybody; everybody reads the same number.

The effect is absolute repeatability. Ten thousand frames into the show, the same four things happen together, tonight, tomorrow and in six months, without anybody being accurate about anything.

Triggered vs timed shows

Shows are run in two broad ways, often combined. In a triggered (or manually-called) show, an operator or show caller fires cues on command, giving live flexibility to follow a performance that varies — ideal when timing must adapt to people. In a timecode-locked show, sequences run automatically to the clock, giving perfect repeatability — ideal for fixed, precisely-choreographed content. Many productions blend both: timecode for the locked sequences, manual cues for the flexible moments. Choosing the right approach for each part of a show is a show-control design decision.

The principle is matching the method to the need: human judgment and flexibility where the show varies, machine precision and repeatability where it must be exact. A live concert might run songs to timecode but call the between-song moments manually; a theatrical show might call most cues live for flexibility. Understanding this trade-off lets you design a show-control approach that is both reliable and responsive.

Timed sections buy precision and lose flexibility: the clock does not wait for an actor who is late or a speaker who overruns. Called sections buy flexibility and lose precision. Real shows mix them, and the design decision is which parts get which.

A good rule: lock what is choreographed, call what follows a human being. And where a timed section can be entered late, decide in advance whether it starts from the top or joins in progress.

LTC, MTC and frame rates

The standard behind all of this is SMPTE timecode, and you will see the name on generators, on console menus and in every specification: SMPTE is the clock, LTC and MTC are two ways of carrying it.

LTC — linear timecode — is an audio signal carrying the clock, distributed on audio cable and understood by almost everything. MTC is the same information carried over MIDI. Both say the same thing in different wires.

Frame rate matters: 24, 25, 29.97 and 30 frames a second all exist, and drop frame is a counting convention that keeps 29.97 agreeing with the clock on the wall. Everybody on a show must use the same rate and the same convention, and it is written down in the production paperwork.

LTC is audio, and that changes everything

Linear timecode is not a data protocol in the way the rest of this chapter's protocols are. It is an audio signal — a harsh, buzzing tone at line level — and every consequence of the job follows from that one fact.

It travels on audio cable, on XLR, through the same patchbays, splitters and distribution amplifiers as everything else in the sound rack. It can be sent down a spare channel of a multicore. It can be recorded onto a track of a multitrack session, which is exactly how a touring band drives lighting and video: a timecode track plays alongside the backing tracks, and every department follows it.

Because it is audio, it has a level, and level is the commonest reason a device will not lock. Too quiet and the reader misses edges; too hot and it distorts into something unreadable. Set it where the receiving device is happy and then leave it alone — and never send it through anything that processes audio, because compression, equalisation and noise reduction all destroy it.

Distribute it properly: one generator, into a distribution amplifier, out to every department. A passive Y-split of a timecode feed loads the signal and produces exactly the intermittent lock failures that are hardest to chase. And keep it away from the audio you are actually listening to: timecode crosstalk into a monitor mix is unmistakable and mortifying.

MTC carries the same clock over MIDI instead. It suits a room where everything already speaks MIDI, it inherits MIDI's cable limits, and it is slightly coarser than LTC. Where both are available, LTC is the one that will still be working in ten years' time on equipment nobody has updated.

Distributing the clock

One generator, distributed to everybody, with the path documented: which output feeds which department, through what distribution, on what cable. Timecode on a long, shared or noisy path degrades, and a system that loses lock behaves as though the show stopped.

Jam sync lets a device take the incoming clock and then keep counting on its own if the signal disappears, which turns a dropout into a survivable event rather than a stop. Know which of your systems can do it and which cannot.

Timecode is not genlock

Genlock aligns when frames are drawn — a video timing reference so that images do not tear. Timecode says what time it is. A system can be perfectly genlocked and playing the wrong part of the show, or perfectly on time and tearing.

On a show with cameras or several video outputs you need both, and they come from different places. Confusing them is the commonest misunderstanding between video and the rest of a production.

Latency and offsets

Nothing is instant. A trigger takes time to travel and a system takes time to respond, and a video chain can be several frames long. Where a moment must land together, measure each path and offset the trigger times to compensate.

Measure rather than guess, and write the numbers on the control plan. "Video fires three frames early" is a fact that survives the person who discovered it.

Timecode, genlock and triggers, separated

Three different things people call sync.

How to do it

1. Agree the frame rate and drop-frame convention with every department.
2. Name one generator as the source, and document its distribution.
3. Confirm every system reads the same numbers as the generator.
4. Programme each department against the clock, roughly first.
5. Run with the real audio and nudge each cue until it lands.
6. Measure latency on the long paths and offset the triggers.
7. Decide what each system does if the clock stops or jumps.
8. Rehearse losing the clock, and rehearse joining the section late.

What goes wrong

Practice it

With any timecode generator and two systems that read it.

The Systems You Will Meet

A reader who has never seen any of this deserves to know what the industry actually runs on. None of these is the subject — the subject is what they all do — but walking onto a job knowing the names is the difference between following a conversation and nodding through one.

Dedicated show controllers

Purpose-built hardware and software for driving many systems: the kind of platform used in attractions, museums and permanent installations, where the controller is a rack-mounted device with real inputs and outputs that boots into the show and runs unattended for years.

Their strengths are reliability, real-world inputs and outputs, scheduling and recovery. Their cost is that they are configured rather than improvised, and changing a show means going back to the programming environment.

Theatre and event cue systems

Software cue lists that play sound, fire lighting, trigger video and talk to everything else — the tool a stage manager's call actually reaches. They live on a laptop at the sound position, hold hundreds of cues, and are the commonest show control system in theatre by a very long way.

They suit called shows: fast to change, readable by somebody else, and happy to be edited between performances. They are less suited to unattended work, where a machine that needs somebody to log in is a liability.

Installed control platforms

In corporate rooms, venues, worship and education, control usually means a room control or audio DSP platform that also drives sources, screens, lighting presets and building systems from a touch panel. Show control there is one behaviour inside a larger control system.

These are programmed by integrators, live for a decade, and are maintained by whoever inherits them — which is why the documentation chapter matters more here than anywhere else in this book.

What each department's own desk speaks

• Lighting consoles: MIDI Show Control, OSC, network protocols, and DMX in and out.
• Media servers: timecode, OSC, DMX or Art-Net, and their own network APIs.
• Video switchers: macros and salvos, contact closures, and a serial or network protocol.
• Audio consoles: MIDI and their own network control for snapshot recall.
• Audio playback and DSP: OSC, network commands, and direct cue firing.
• Automation: proprietary interfaces, and a permissive that stays with a person.
• Building systems: a room control platform, usually over a network.

Choosing what to build on

Three questions settle it. Is the show called or unattended? Will it be changed daily, or configured once and left? And who will maintain it after you — a technician on the floor, or an integrator in two years?

A called, changing, staffed show wants a cue system. An unattended show running for years wants a dedicated controller. A room that is mostly other things with a show inside it wants the installed platform that is already there.

The one that is always available

A person. On a small show the cheapest, fastest and most reliable show control system in the world is an operator with a cue list and a pair of eyes, and there is no shame in recommending one.

Automation earns its place on precision, repetition and scale. Where none of those apply, a person is not a fallback — they are the right answer.

What to build on, by show

The three questions, answered.

Practice it

For a show you know well.

The Logic Inside a Controller

A cue list is a straight line: this, then this, then this. Most real shows are not straight lines. They wait for things, repeat things, skip things, and have to know where they are when somebody switches them on at nine in the morning. That is logic, and it is what separates a show that runs itself from a list somebody has to drive.

Lists and state

A cue list knows only what is next. A state machine knows where the show is: idle, pre-show, running, paused, resetting, faulted. Every unattended show is really a state machine with cues inside it, whether or not anybody drew it that way.

Drawing it is worth the twenty minutes. Write the states down, write what moves the show from each one to the next, and the awkward questions answer themselves: what happens if somebody presses the button during the show, what happens at closing time, what happens after a power cut.

Variables and conditions

Controllers hold values — a counter, a flag, the number of people waiting, whether the doors are open — and can branch on them. That turns one show into several: a short version at quiet times, a different ending on the last performance of the day, a skip when a projector has failed.

Keep the conditions few and name them plainly. Logic that only its author understands is worse than no logic, because the next person cannot safely change anything.

Timers, waits and loops

A wait holds for a duration; a timer fires something later; a loop repeats until told to stop. Between them they build almost every unattended show: an idle loop that plays attract content, a timer that starts the show on the hour, a wait that holds the doors closed for thirty seconds.

The trap is nesting them until nobody can predict the behaviour. Prefer a flat structure with clear states over a clever one with three loops inside each other, and test the awkward timings: the show starting while the previous one is still resetting.

Coming back mid-show

A controller that restarts has to decide where the show is. The honest options are: go to a known safe state and wait; resume where the clock says; or restart the show from the top. All three are legitimate and the wrong one is having no answer.

Whatever is chosen, the safe state has to be genuinely safe — house lights up, audio muted, nothing moving — because a restart usually happens when something has already gone wrong.

Keeping logic readable

• Name states and variables in words a stranger would recognise.
• Keep the number of states small enough to draw on one page.
• Put the drawing in the documentation pack.
• Avoid logic that depends on how long something took.
• Log every state change, so a fault can be read afterwards.
• Test every transition, including the ones that should be impossible.

A show as states rather than a list

Five states cover most unattended shows.

On the job

A museum show is triggered by a button. Two visitors press it eleven times while the show is running, a school group arrives during the reset, and at six o'clock the building shuts down mid-sequence. None of those is unusual, and all three are answered by a state machine drawn in twenty minutes.

What goes wrong

Practice it

Draw a show you know as a state machine.

Designing the Control Plan

Before anything is built, somebody draws what talks to what. That drawing — the control plan — is the real deliverable of show-control work, and it is what everybody else in the production argues with, agrees to, and builds from.

What a control plan shows

Every system on the show as a box, every link between them as a line, and on each line the protocol, the direction and what it carries. Alongside it: the clock, its source and its distribution; and a note of who owns each system.

It is a signal-flow diagram for control rather than for audio or video, and it is read the same way: find the sources, follow the lines, arrive at the targets, and be able to say what happens at every step.

Deciding what triggers what

Work from the show's moments rather than from the equipment. For each moment, ask what has to happen, how precisely it has to land, and whether it follows a person or a clock. That produces the trigger design almost by itself.

Then simplify. Every link is something that can fail, so a plan with four solid links beats one with eleven clever ones. Complexity has to earn its place in every single line.

The control matrix

A useful companion to the drawing: a table of cues down the side and systems across the top, with a mark where a cue touches a system. It shows at a glance which cues are the big ones, which systems are heavily used, and where a single failure would be most visible.

It is also what other departments read. A lighting programmer wants to know which cues touch them and nothing else, and a matrix answers that in one look.

Documenting protocols and addresses

For every link: the protocol, the physical path, the addresses and ports, device numbers, and what the message actually is. A note saying "OSC to the server" is not documentation; the address, the port and the argument are.

Keep it with the cue list and the plan, issue it with a date, and update it when anything changes. This is the pack the next technician inherits, and it decides whether the system can be maintained at all.

Writing down the failure plan

Beside every automated moment, write what happens if it does not fire and who does what. "If the server does not start, the operator triggers it by hand from the local cue list" is a plan; "we would notice" is not.

This is the part people skip and the part that matters on the one night it is needed. It costs an hour to write and it is read in ten seconds under pressure.

The control documentation pack

Five documents. Together they are the system; separately they are notes.

How to do it

1. List the show's moments, before listing any equipment.
2. For each, note what must happen, how precisely, and whether it follows a person.
3. Decide which moments are timed and which are called.
4. Draw the systems as boxes and the links as lines, with protocols on the lines.
5. Name the clock source and draw its distribution.
6. Simplify: remove every link that is not carrying its weight.
7. Write the protocol and address list, and the failure plan.
8. Circulate all of it and collect objections before anything is built.

What goes wrong

Practice it

Take any show you have worked on and draw its control plan.

Networks for Show Control

Most show control now travels on a network, which means the reliability of the show is the reliability of a network somebody configured. That is good news, because networks are predictable — as long as nobody treats the show's network as a general-purpose one.

Why control gets its own network

Control traffic is small, constant and time-sensitive. Media traffic is enormous and bursty. Office traffic is unpredictable and full of things nobody asked for. Put them together and the small time-sensitive one suffers first.

So control lives on its own network, or on its own VLAN within a larger one, with only the devices that belong there. On a large production there may be separate networks for control, for audio, for video and for everybody's laptops.

Addressing that a human can read

Give devices fixed addresses in a scheme somebody can remember: a range per department, a pattern by device type, and a written list. Addresses handed out automatically are fine for laptops and wrong for a show system that another machine has to find by number.

Write the addressing scheme down beside the control plan. Half the "nothing is triggering" calls in this industry are an address that changed when something rebooted.

Switches, cabling and the boring things

Managed switches, labelled ports, documented VLANs, and cable runs that somebody can trace. Redundant paths where the show justifies them, and physical separation where two paths are supposed to be independent.

Beware the single cable through a doorway carrying two supposedly redundant links. Redundancy that shares a route is decoration.

What breaks control networks

• A device that gets its address automatically and changes it after a reboot.
• Wireless in the path, where it was never meant to be.
• A laptop plugged in to "check something" that floods the network.
• A firewall or a router between two systems that need to see each other directly.
• Multicast traffic from a video system arriving where it was not expected.
• One switch with everything on it, and no spare.

Testing the network before the show

Prove each link on the show network, at the show's addresses, with the show traffic running. A control message that works on a quiet bench and fails in a venue is a network problem, and it is far cheaper to find on the Tuesday.

Keep a monitoring tool to hand that shows you the actual messages. Seeing traffic is the difference between debugging and guessing, and it takes minutes to set up.

Control network decisions

Each one is cheap at design time and expensive on site.

On the job

A conference triggers perfectly in the rehearsal room and fails in the ballroom. The venue's network hands out addresses automatically; the server has a different one from yesterday, and every OSC message is going to a machine that is no longer there.

What goes wrong

Practice it

On any two-system control rig.

Building & Running a Show-Control Show

Building is the easy half. The work that decides whether the show survives is proving each cue cold, deciding what happens when a system does not answer, and rehearsing the version where somebody does it by hand.

Programmed carefully and rehearsed, a controlled show runs flawlessly and repeatably.

Building the show

Building a show-control show follows a clear flow: map out the sequence of the show (what happens when, across all systems), program the cues (building each moment's actions into the controller), connect the systems (with the right protocols so triggers reach them), rehearse thoroughly (running the cues with all systems to verify each fires correctly and on time), and then run it on GO. The bulk of the work is the programming and rehearsal — careful, detailed work done before the show — which is exactly what makes the live show reliable.

This is systems-thinking work: you must understand each system being triggered, the protocols linking them, and the sequence of the whole show, then assemble it into a coherent, tested cue list. It draws together knowledge from across the trade — lighting, video, media servers, audio, networking — into the integration layer. The show-control programmer is a kind of systems integrator and conductor, which is why it is a sophisticated, valued role.

Build in the order the show happens, one cue at a time, testing each as it is made. A controller full of untested cues is a list of hopes, and the moment to find out that a command is wrong is while you are typing it.

Name everything as you go, in the same words the cue list uses. The people reading your screen during a tech are not you.

Reliability and running it

Because show control coordinates everything, its reliability is critical — a show-control failure can affect the whole show, not just one system. So reliability thinking is paramount: thorough programming and testing, rehearsing every cue, building in fallbacks (the ability to fire systems manually if the controller fails, backup systems for critical shows), and understanding the whole integrated system well enough to troubleshoot it. A well-built show-control show runs flawlessly and repeatably; a poorly-built one can fail spectacularly, so the discipline of careful building and testing is essential.

Running the show is then the calm payoff: advancing through the cue list on GO (or letting timecode run), monitoring that systems respond correctly, and handling the show with the confidence that comes from thorough preparation. When something does go wrong, the operator's deep understanding of the integrated system and the systematic troubleshooting method isolate the issue. Mastering cues, triggering, protocols, synchronisation, and reliable building makes you able to tie a whole production together — one of the most advanced and rewarding integration skills in the field.

On the night the job is watching. Keep the controller's log or monitor visible, keep the next cue in view, and keep your hands off anything that is working. A show-control operator who is busy is usually about to cause something.

Know the state of the show at all times: which cue was last fired, what each system should be doing now, and where you would rejoin if everything had to be restarted.

Practical sign-off

Show control is learned by building sequences. The reader maps a sequence, programs cues that trigger multiple systems, connects systems with appropriate protocols, rehearses, and runs the show on GO with a fallback. A mentor signs off when the reader can build and run a small integrated show-control sequence.

• Mapped a show sequence across multiple systems
• Programmed cues that trigger several systems together
• Connected systems using appropriate protocols
• Rehearsed and ran the sequence on GO with a fallback plan

Testing cues cold

A cue you can only test by running the show is a cue you cannot test. Build so that each one can be fired on its own, with the systems in a known state, and prove it that way before it ever runs in sequence.

Where a system is not present yet, simulate it: something that listens on the same address and reports what it received. That way the control design is proved before the equipment arrives.

Error handling, and what a missing answer means

Most show-control protocols do not report failure; they report nothing. So design the show to notice: use protocols that reply where you can, log every trigger, and give the operator something that goes red rather than something that simply stays quiet.

Then decide, per cue, what should happen when a target does not answer. Continue, hold, retry, or alert somebody — all are legitimate, and the wrong one is having no answer at all.

Logging, and finding the trigger that did not arrive

When something does not fire, there are only four possibilities: it was never sent, it was sent to the wrong place, it arrived and was misunderstood, or it arrived and the target failed. A log and a traffic monitor separate those four in under a minute.

Without them you are guessing in front of a producer. Set both up before the show, not after the first failure.

Manual fallback

Every automated moment needs a way of being done by hand: a local cue on the department's own desk, a button, or a person who knows what to press. Write it beside the cue in the running order, and rehearse it.

The measure of a good control design is not how clever it is when everything works. It is how ordinary the evening becomes when one part of it does not.

When a cue does not fire

Four possibilities, separated by a log and a traffic monitor.

How to do it

1. Fire every cue individually, cold, with the systems in a known state.
2. Fire the sequence from the top, without an audience, twice.
3. Deliberately break one link mid-run and watch what the show does.
4. Practise the manual fallback for the three most important moments.
5. Restart the controller mid-show and rejoin, to prove you can.
6. Check the log afterwards and confirm it recorded what happened.
7. Write the running order with the fallback beside each automated moment.
8. Save and export the show file, and note the versions of everything.

What goes wrong

Practice it

With a small control rig and two targets.

Interlocks, Permissives and Safety

There is a line in this work that is never crossed. Some systems move heavy things, burn things or put light into people's eyes, and the systems that stop them hurting somebody are not part of the show.

Control is not safety

A show controller can ask an automation system to move a piece of scenery. Whether that move is allowed to happen is decided by the automation system's own safety circuits: emergency stops, position limits, permissives and the operator who holds them.

The distinction is absolute. Control systems are built for convenience and flexibility, and they fail in ordinary ways — a network drop, a wrong address, a crashed application. Safety systems are built to fail into a safe state, and are certified to do so.

Interlocks and permissives

An interlock prevents something happening unless a condition is met: a door is closed, a zone is clear, a key is turned. A permissive is a person or a system saying "you may" — a hold-to-run button, a laser operator's enable, a pyrotechnician's key.

These are wired, physical and independent of the show controller. A show controller may request, and the interlock decides. Anything that lets a controller bypass an interlock is a fault, not a feature.

Effects that are never simply triggered

• Pyrotechnics: fired only by a licensed operator, with their own arming and keys.
• Lasers: enabled by a trained operator, with interlocks and zone protection.
• Stage automation: moves that require a permissive and a clear zone.
• Flying performers: always under direct human control.
• Anything that heats, cuts, falls or carries a person.

What a show controller may legitimately do

It may say when the moment has arrived — arm a sequence, cue an operator, light a standby lamp, send a request that a permitted operator then acts on. That is genuinely useful, and it is where control and effects meet safely.

The difference is that a human with training and authority remains in the loop for the dangerous part. Automating the moment does not mean automating the decision.

Emergency stop, and what it must do

An emergency stop removes the ability of a system to move or fire, immediately, by a route that does not depend on software. It is tested, documented and known to everybody on the floor.

As a show-control person your job is to know where they are, know what each one stops, never route one through your system, and never design anything that assumes one will not be pressed.

Saying it out loud

When somebody asks for a controller to fire something dangerous directly — and they will, usually for good reasons of timing — the answer is to explain the line and offer the safe version: the controller cues the operator, the operator fires.

Put it in writing. This is the one area of show control where being the person who insisted is worth more than being the person who found a way.

Control and safety, side by side

Two different kinds of system with two different purposes.

On the job

A producer wants the pyrotechnic hit locked to timecode so it lands exactly on the beat. The answer is a cue that lights the pyrotechnician's standby lamp four seconds early and a second one that signals the moment; the operator, who can see the stage, fires. The beat is hit and nobody is standing in the zone.

What goes wrong

Practice it

On any show with automation, pyrotechnics or lasers.

Cue Lights, Comms and the Show Stop

Two things sit either side of a control system and matter more than any of it: the way the people running the show talk to each other, and what happens when the building tells everybody to stop.

Cue lights

A cue light is the oldest show control system there is: a lamp that goes on to warn and off to go, or red for standby and green for go. It exists because a performer or a technician in the dark cannot hear a headset and cannot see a hand.

Cue lights are driven by the stage manager's desk and, increasingly, by the same controller that fires everything else. When you automate them, keep the convention the house already uses — reversing what a red light means is a genuinely dangerous thing to do.

Comms, and where the caller lives

The show is called on comms: a ring of headsets connecting the stage manager to lighting, sound, video, flys, followspots and stage crew. Show control does not replace it — it reduces how many people have to act on each call, and the call still happens.

Know the channels, know who is on which, and keep your own traffic short. The person calling the show has to hear their own cues over whatever you are discussing.

The show stop

Every show has a way to stop: a word on comms, a button, a procedure. In theatre a stop is called by the stage manager and everything holds; in attractions it is usually a button that puts every system into a safe state; on a concert it is the production manager's decision.

A control system must make a stop easier rather than harder. That means a single, obvious way to halt what it is doing, a defined safe state to land in, and no sequence so clever that stopping it is complicated.

Fire alarm and life safety

When a building's fire system activates, everything changes: house and egress lighting come up, sound is muted or replaced by the evacuation message, moving things stop, and the audience leaves. Those behaviours belong to the building's life-safety system, which is certified and independent of anything you build.

Show control's role is to get out of the way: release control of house lighting, stop sending audio, and stop asking anything to move. In venues this is an interface the integrator builds and the authorities inspect, and it is never something a show designer improvises.

Rehearsing the stop

Rehearse it like any other cue. Stop the show mid-sequence in a technical rehearsal and watch what every system does. Then restart, and watch that too. Most show-stop disasters are recovery problems: the stop worked and nobody knew how to get going again.

Write down who calls a stop, what each department does, and how the show resumes. It belongs on the same page as the running order, and it should be the shortest, clearest thing on it.

Stopping, and who owns it

Three different stops, with three different owners.

How to do it

1. Agree who may call a stop, and on what words.
2. Run the show and stop it mid-sequence.
3. Watch every department: what held, what kept going, what went dark.
4. Land in the safe state and confirm it is genuinely safe.
5. Restart from the agreed point and watch the recovery.
6. Fix whatever did not behave, and repeat.
7. Write the procedure on one page, beside the running order.
8. Tell every department where that page is.

What goes wrong

Practice it

For a venue you know.

Where Show Control Lives

The same protocols and the same thinking turn up in very different rooms, and each sector has its own rhythm. Knowing which one you are in tells you how much to automate, who calls the show, and what happens when something fails.

Theatre: the called show

A stage manager calls every cue from a book, and the control system exists to make one call fire several departments. Shows run for months and must be identical; rehearsal is long; the paperwork is exact; and the person calling is in charge of the evening.

Show control here is often a cue system on a laptop in the sound department, firing lighting over MSC and video over network messages. The measure of it is that the stage manager's book and the cue list agree, page for page.

Concert and touring

Songs are locked to timecode; the talking between them is called or busked. The rig is rebuilt every day in a different room, so the control design has to survive being unplugged and reassembled by tired people, and the fallback has to be quick.

Lighting is usually in charge: the console drives the servers, and the lighting operator is the de facto show controller. Timecode arrives from playback or from the musical director's rig, and the question of who owns the clock is settled before the first show of the run.

Corporate and conference

A run of show rather than a script, a dozen presenters, no real rehearsal, and a producer changing the order an hour before doors. Automation earns its place on the opening and the awards moments, and everything else is called live because the day will change.

The control system has to be readable by somebody who did not build it, because on a three-day conference the operator may change. Name everything plainly, keep the list short, and keep a manual way of doing every automated moment.

Themed entertainment and attractions

The most demanding sector, and the one where show control is a career rather than a task. Shows run hundreds of times a day, unattended, for years, interlocked with ride systems, and they must start, stop and recover on their own.

Everything in the chapter on installed and unattended systems becomes mandatory: watchdogs, automatic recovery, reporting, sequenced startup, and a failure state a visitor can accept. The engineering standards here are closer to industrial control than to live events.

Museums, visitor centres and worship

Gallery shows on a schedule, triggered by a button or a sensor, maintained by somebody who is not a technician. Worship adds volunteers, weekly repetition and a congregation, with a small team running a complex system on one press.

Both reward simplicity and documentation far more than cleverness. The system that survives is the one whose operating notes fit on a page and whose failure state is a holding image rather than a black screen.

Broadcast, cruise and the rest

Broadcast galleries automate rundowns, routers and playout. Cruise ships run theatre-scale shows with rotating casts and crews and no possibility of calling an engineer. Esports and large-scale streaming run corporate-style control at concert scale.

Between them these sectors employ a great many people who would not describe themselves as show control specialists, and all of them are doing this job.

The sectors, and what each one demands

Same protocols, different rhythm and different risk.

Practice it

Pick the sector you work in, or want to.

Installed and Unattended Systems

A great deal of show control is not a show at all. It is a museum gallery that starts itself at nine and stops at six, a meeting room that wakes when somebody walks in, an attraction that runs the same ninety seconds four hundred times a day with nobody watching it.

What changes when nobody is there

In a theatre, a failure is noticed instantly by a room full of professionals. In an install, it may be noticed by a visitor, a week later, or never. So the design has to notice for itself: recover automatically where it can, report when it cannot, and fail into something acceptable rather than into a black screen.

The other change is time. An installed system runs for years, through firmware updates, staff changes and IT policy changes, and the person who built it will not be there.

Startup, shutdown and the daily cycle

Systems come up in an order: displays before the players that feed them, network before the devices that need it, audio amplifiers last so that nothing thumps. That order is designed, written down and automated.

Shutdown is the same in reverse, and both are rehearsed as sequences. The commonest installed-system fault in the world is a device that came up before the thing it needed and gave up.

Triggers when there is no operator

A schedule starts and stops the day. A sensor starts a piece when somebody arrives. A button lets a visitor begin. An occupancy signal from the building tells the room it is being used. Each of them is a cue source, and each needs a decision about what happens if it misfires.

Think about the awkward cases: two people arriving during a show, somebody pressing the button eight times, a sensor left permanently triggered by a coat on a hook.

Watchdogs, recovery and reporting

A watchdog notices that something has stopped and restarts it. Systems return to a known state on their own, log what happened, and tell somebody. That reporting — an email, a dashboard, a light in the office — is what makes the difference between a system that is maintained and one that quietly degrades.

Design for the person who will look after it, who is usually not technical, usually busy, and usually the only one there.

Handing it over

The client inherits everything: the plan, the cue list, the address list, the failure plan, the passwords, the licences, the show files and a plain account of how to start it, stop it and recover it.

Train somebody, and write the one-page version they will actually use: how to restart the system, what the three commonest problems look like, and who to call. Everything else can live in the pack behind it.

What an installed system needs that a show does not

Nobody is standing next to it when it fails.

How to do it

1. Write the startup and shutdown order and automate both.
2. Power the whole system down and bring it up cold, several times.
3. Trigger every input, including the awkward repeats and the impossible ones.
4. Kill a device mid-show and watch what recovers and what does not.
5. Set the watchdogs and prove they restart what they should.
6. Set up reporting and confirm somebody receives it.
7. Write the one-page operating note and train the person on site.
8. Hand over the full pack: plan, lists, credentials, licences, files.

What goes wrong

Practice it

Take any installed AV system you can visit.

Interactive Shows

In museums, attractions and exhibitions the audience is the trigger. They press the button eleven times, walk away halfway through, arrive in groups of thirty, and lean on the sensor with a coat. Designing for that is its own discipline, and it is mostly about the awkward cases.

What triggers an interactive show

A button somebody presses, a presence sensor that notices an arrival, a schedule that starts the show regardless, an occupancy signal from the building, or a person on a desk with a remote. Most installations use two: a schedule for the day and a trigger within it.

Each has a different failure. Buttons stick and get pressed repeatedly; sensors trigger on coats, cleaners and sunlight; schedules do not know about bank holidays; and remote controls get lost.

The awkward cases

• The trigger fires while the show is already running.
• It fires during the reset, before everything is back at the top.
• It fires thirty times in a minute.
• Nobody triggers it for four hours and the equipment goes to sleep.
• Somebody triggers it and leaves before it starts.
• Two zones are triggered at once and the audio conflicts.

Queueing, ignoring and restarting

For a repeat trigger there are three honest behaviours: ignore it until the show is finished, queue one repeat and no more, or restart from the top. Which is right depends on the show's length and on whether a restart would annoy the people already watching.

Short shows usually ignore; long shows usually queue; nothing should ever restart in front of an audience that is halfway through, unless the piece is designed for it.

Designing for people who are not paying attention

Visitors do not read instructions, do not wait for a show to finish, and assume a button that does nothing is broken. So give feedback the instant something is pressed — a light, a sound, an image — even when the show cannot start yet.

And design the ending: a show that stops dead and leaves a black screen reads as broken. Return to attract content, visibly, so the next person knows it works.

Multiple zones and neighbours

Galleries have several shows in earshot of each other. Either they are synchronised, so the whole room plays one thing, or they are staggered and directional, so two pieces do not fight. That is a design decision made with the exhibition designer, and show control implements it.

Where zones share a clock, one controller usually runs the building and the zones are states inside it, which is far easier to reason about than five independent systems with opinions.

Triggers, and how each one fails

Design for the failure, not for the demonstration.

On the job

A gallery piece is triggered by a button and runs four minutes. A visitor presses it, watches ninety seconds and leaves; the next presses it twice and is confused when nothing changes. The fix is not technical: ignore repeats, light the button while running, and return to attract content visibly at the end.

What goes wrong

Practice it

Visit any museum or visitor centre with interactive pieces.

Conduct, Handover and Where This Leads

Show control is a job about other people's systems. Almost everything that makes somebody good at it is conduct: what you change, what you announce, what you write down, and what you refuse.

Cue numbers belong to the production

Once four departments have written a number in their paperwork, that number is a shared interface. Renumbering it, reusing it, or quietly inserting something in its place breaks other people's shows in ways they will discover in front of an audience.

Announce every change, re-issue the list, and mark what moved. It takes two minutes and it is the single most appreciated habit in this work.

Changing somebody else's system

You will often need something changed on a desk or a server you do not own: a clip renamed, a cue added, a channel freed. Ask the person who owns it, watch them do it if you can, and write down what changed.

Never make the change yourself because it is quicker. The five minutes you save are paid back with interest the first time they cannot find what you did.

What to write down, always

• Every address, port and device number.
• Every change to a cue list, with the date.
• Every measured latency and offset.
• Every decision about what happens on failure.
• Every request you refused on safety grounds, and why.
• Every version: software, firmware, show files, licences.

Working in the production meeting

Show control is designed in meetings, where the people who own the systems agree what will talk to what. Turn up with the drawing, ask what each department can send and receive, and write down who owns the clock.

Most of the failures in this subject are decided in that room, weeks before anybody plugs anything in.

Where this work leads

From here the routes are show-control programming on large productions, systems integration in installed venues, technical direction — where you own the whole technical shape of a show — and design work for attractions, museums and broadcast.

All of them are paid for the same thing: a system other people can rely on, documented well enough that somebody else can keep it running.

Getting better at it

• Make two systems talk that were not designed to, and document it.
• Rebuild a show you ran as a control plan, from memory, and check it.
• Learn one controller platform properly rather than three badly.
• Ask each department what they wish control people understood about their system.
• Practise the failure cases; the happy path teaches nothing.
• Keep your own template pack: plan, matrix, address list, failure plan.

Where show control work leads

All of it is built on documenting a system somebody else can run.

Practice it

Do one of these on your next production.

Glossary

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal