Event Show Control: Coordinating Media, Light, Sound, and Motion

Event show control coordinates the cues and states of systems such as media, sound, lighting, and interactive software. It defines what starts an action, which systems respond, and how the sequence progresses. A useful design also explains readiness, interruptions, recovery, and operator responsibility.

The audience may see one coherent moment while several departments deliver it. A product appears, the image changes, the sound shifts, and the lighting reveals a new area. The control plan connects these actions without leaving their timing or ownership to assumption.

Begin with a cue narrative

Describe the sequence in plain language. Identify what the audience should experience and what the operator needs to do. Separate a timed sequence from an interaction that waits for a visitor’s action or a live presenter’s decision.

Give cues consistent names. A cue list should make sense to the people calling, programming, and operating the experience. “Start” is not specific enough when it could refer to a playback file, lighting sequence, visitor session, or physical movement.

Then assign a source of authority. Which system or person advances the sequence? Which departments confirm that they are ready? How is a hold communicated?

Match the coordination method to the behaviour

Some sequences can use scheduled playback. Others need manual cues, event messages, or a shared time reference. Interactive experiences may combine several methods.

QLab’s documentation describes interfaces including OSC, MIDI, and timecode. These are examples of mechanisms used in show workflows. A project still needs to define the message, timing expectation, acknowledgement, and failure behaviour for each connection.

For multi-computer visual rendering, Epic Games’ nDisplay documentation describes a networked rendering architecture. Rendering coordination and show cueing solve related but different problems; determine which the experience actually requires.

Build an interface and cue matrix

Field	What to define
Cue name	A unique name understood across departments
Trigger	Operator action, schedule, visitor input, or another system
Receiving system	The device or application expected to respond
Expected result	The visible, audible, or logical state after the cue
Readiness	What must be confirmed before the cue can run
Interruption	What the operator should know if the response is incomplete
Recovery	The agreed path back to an appropriate state
Owner	The person or team responsible for the interface

This matrix is a planning aid. It is not a substitute for specialist control design or any separate safety functions required by the installation.

Design the operator’s view

Operators need to understand the current state without opening several development tools. Present the information needed to decide whether to proceed, hold, reset, or escalate.

Avoid relying only on a decorative animation to indicate readiness. Use clear labels and states. If a subsystem is unavailable, the interface should identify the affected function and the permitted response.

Distinguish a visitor reset from a system restart. Restarting one application may leave another system in a different state. The recovery process needs to account for the integrated experience rather than assume every component returns together.

Plan for an interrupted sequence

Consider a hypothetical product reveal in which a presenter pauses before the final cue. The sequence needs a stable holding state. If a media service becomes unavailable, the operator needs a defined alternative rather than repeating the trigger and hoping for a response.

That example illustrates a control question, not a delivered XSEDES project. The broader principle is to define what the experience should do when the expected sequence cannot continue.

For physical movement, keep creative cueing distinct from the architecture and procedures responsible for safe operation. Qualified specialists should determine the appropriate controls and protective measures for the actual installation.

Rehearse transitions and recovery

A rehearsal should include start-up, normal operation, holds, permitted interruptions, recovery, and shutdown. Test the approved scenarios with the people who will operate the system.

Record the software and content versions used. Check whether changes to a media file, network setting, or external service affect the control sequence. A late content change may require targeted rechecking even if the original cue list passed.

Make the test result specific: which sequence ran, under what conditions, with which systems, and which limitations remained. “Everything worked” is difficult to use when the setup later changes.

Hand over a repeatable operating process

Include the system overview, cue list, interface record, start-up and shutdown instructions, approved recovery steps, configuration backups where agreed, and escalation contacts. Explain who can change the configuration and how updates are checked.

For venues, define daily checks and support responsibilities. For touring work, document how the system is verified after reinstallation. For international projects, establish who is available locally and when remote assistance can realistically be provided.

Frequently asked questions

Is show control the same as media playback?

No. Playback is one function. Show control coordinates the actions and states of several systems or departments, which may include playback.

Does every installation need a central controller?

No. The architecture should suit the required behaviour. Simple experiences may need limited coordination; complex sequences need a clearer system design and ownership model.

Can show control handle safety functions?

Do not assume that a creative control platform provides the required safety functions. Those responsibilities need a separate specialist assessment and an appropriate implementation.

Coordinate the experience before the rehearsal

Share your system concept with XSEDES, including the departments, visitor actions, and cue dependencies. Read kinetic installation planning, prototype testing, and the event technology brief to prepare the interface discussion.