Lighting Operation

Introduction

A lighting console is a machine for remembering. It remembers which fixture is which, what each one was doing in every moment of the show, and in what order those moments happen. The operator's job is to teach it accurately and then play it back without anybody noticing that a person is doing it.

This book is the desk and everything around it: the patch that makes the rig controllable, the palettes that make it workable, the cues that make it a show, the rehearsal where the show is actually built, the hour on GO with an audience in, and the ten minutes when a fixture is doing something nobody asked for.

What this book covers

• The console's three jobs — patch, program, playback — and the workflow through them.
• The plot, the hookup and the magic sheet, and what each tells an operator.
• Patching: profiles, addresses, universes, organisation, and proving it against the real rig.
• DMX cabling, splitters, terminators, lighting over a network, and RDM.
• Groups and palettes, and why a show built on them can be re-focused in one move.

• Recording cues, tracking against cue only, timing, and the cue stack.
• Faders, executors, effects engines and everything that is not the GO button.
• Focus sessions, technical rehearsals, working with a designer and being called by a stage manager.
• Busking a show with no plot, and running to timecode when something else is in charge.
• Moving lights, LED colour, haze, power, safety, show files and load-out.

Who this is for

Technicians who know what a fixture and a DMX address are and now have to drive the desk: house operators, programmers in training, and anybody who has been handed a console an hour before a show. It assumes Lighting Basics for fixtures, addressing and the properties of light.

How to Use This Book

Read it once, then keep it beside a console. The chapters follow a production: the rig and its paperwork, the patch, the data, the looks, the cues, the rehearsal, the show, and what happens when it goes wrong.

Build a file as you read

Every chapter about programming is worth an hour on a desk, real or offline. Patch ten fixtures, build groups, record five cues, make one of them track and one of them block, and run them. An offline editor on a laptop teaches most of this for nothing.

Keep a notebook

The other habit is a small notebook, and it is the one that outlasts this book. An operator's work is full of numbers nobody will repeat for you -- the address the last fixture on the truss ended at, the mode a house unit is set to, which menu on this desk hides the patch, the focus note the designer gave on Tuesday that nobody wrote down. Write them by hand as you meet them.

Two pages are worth keeping permanently. One is a list of the venues you have worked in and what is strange about each house rig, because you will go back. The other is the running list of things that went wrong and what fixed them, which is how a fault you have seen once stops costing you an hour the second time.

A note on the words

Console vocabulary is brand-specific and inconsistent. Palettes are presets on some desks and focuses on others; executors, playbacks and faders overlap; a cue is a memory, a step or a state depending on who trained you. This book uses the words most widely understood and names the alternatives where they matter.

A note on safety

Lighting rigs are overhead, hot, heavy and electrically live. Nothing here qualifies you to rig a fixture, to work at height or to do electrical work. It teaches you to recognise the hazards, to work within your training, to keep people out from under a moving rig, and to stop work that is unsafe.

Where this book sits

This book assumes Lighting Basics for what a fixture, a DMX address and a cue are. It does not assume you have ever sat at a console with a room waiting for you.

What pairs with this

• Show Control Fundamentals — what happens when something else presses GO
• Rigging Awareness — the rig your fixtures hang from

Where it leads

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

• Lighting Intermediate — deeper programming and larger rigs
• Lighting Automation — moving lights and automated rigs in depth
• Lighting Design — deciding what the show looks like, not only building it

The Console's Jobs

Every console ever made does three things: it learns the rig, it learns the show, and it plays the show back. Buttons, screens and syntax differ wildly; those three jobs do not, and holding them in mind makes an unfamiliar desk readable in an afternoon.

A lighting console does three things: patch, program, and play back. Everything fits in those.

Patch, program, playback

A lighting console — the desk that controls the rig — does three core jobs, and understanding them organises everything. Patch: telling the console what fixtures are connected and at what DMX addresses, so it knows how to control each one. Program: building the looks and cues — selecting fixtures and setting their intensity, colour, beam, and position, then recording those states. Playback: running the show — triggering the cues so the lights do what you programmed, live. Patch, program, playback: set up the fixtures, build the show, then run it. Every console task is one of these three.

This builds directly on Lighting Basics: patching uses the DMX addressing you learned, programming sets the four properties of light you learned, and playback runs the cues you learned about. The console is where all that theory becomes hands-on operation. Holding the patch-program-playback structure in mind makes any lighting console — however complex its specific buttons — understandable, because everything it does serves one of these three jobs.

Patch is the desk learning the rig: what each fixture is, where it is addressed and what it can do. Program is the desk learning the show: groups, palettes, looks and the cues that hold them. Playback is the show happening: cues fired in order, in time, live.

Ask of any unfamiliar control which of the three it serves. If you cannot say, you have not understood it yet — and on most desks the answer is obvious the moment the question is asked.

From rig to run show

The overall workflow flows through those jobs in order: patch the fixtures (so the console controls the real rig), build looks and record them as cues, sequence those cues into a cue stack (the ordered list that is the show), and then run the show on GO. This is the same prepare-then-execute pattern found across live production — the programming work happens before the show, so the live show is running prepared cues. Understanding this flow tells you what you are doing at each stage of preparing and running a lighting show.

This connects lighting operation to show control and the wider production: the lighting cues are part of the show, run in coordination with everything else, sometimes triggered by a show controller or run to timecode. The lighting operator prepares the rig and the cues, then runs them in step with the show. The flow from patch to run is the backbone of operating lights, and each chapter of this book deepens one stage of it.

The order is fixed, and skipping a stage costs more than it saves. Patch, prove the patch, build groups and palettes, record cues, sequence the stack, rehearse it, then run it. Programming happens before the audience, so the show is prepared cues rather than live invention.

Where the show is busked rather than cued, the same order still applies. You are building playback material in advance instead of a stack, and the preparation is what makes the improvisation possible.

What an operator actually does, hour by hour

In the morning: check the rig is as the plot says, patch, prove, and fix what does not agree. Through the day: groups, palettes, focus with the designer, then cues. In the evening: run the show, watch the stage rather than the desk, and write notes for tomorrow.

Very little of the job is pressing GO. Most of it is preparation, and the quality of the preparation decides whether the show is calm.

Desks differ; the model does not

Theatre desks are built around a tracking cue stack and a stage manager calling GO. Concert desks are built around executors, palettes and playing live. Architectural and corporate desks are built around presets and triggers. All three are still patch, program, playback.

This is why an operator who understands the model can be useful on a strange desk quickly, and why somebody who only memorised one desk's buttons cannot.

The three jobs, and what belongs to each

Every control on every console serves one of these.

On the job

An operator is handed an unfamiliar console ninety minutes before a corporate show. They find the patch screen, the group and palette buttons, the record function and the playback faders — four things — and run the show successfully without ever opening a manual, because they knew what they were looking for.

What goes wrong

Practice it

Take any console, hardware or offline.

The Rig and the Paperwork

Before a console is switched on, somebody has drawn the rig. The plot says what is hung where, the hookup says what is plugged into what, and the magic sheet is the one page an operator actually keeps in front of them. An operator who cannot read them is guessing all day.

The light plot

A light plot is a scale drawing of the rig seen from above: every fixture in its position, drawn as a standard symbol, with its channel number, its type, its colour and often its purpose. A section drawing shows the same rig from the side, for angles and trim heights.

Read it the way you would read any drawing: find the title block, check the revision, find the legend, then find your own department's information. The plot tells you how many fixtures of each type to expect and where they point before you have seen the room.

The hookup and the instrument schedule

The channel hookup lists every channel in order and says what is on it: fixture type, position, address, colour, purpose. The instrument schedule lists the same information sorted by position instead. Between them they are the patch, written down before the patch exists.

Patch from the hookup rather than from memory, and mark it up as reality differs — a fixture swapped for another type, an address changed on the floor, a unit that did not turn up.

The magic sheet

A magic sheet is the designer's and operator's cheat sheet: a single page, drawn rather than tabulated, grouping the rig by what it does — front light, back light, sides, specials, the moving lights — with the channel or group numbers beside them.

It exists because during a tech nobody has time to read a hookup. Make one for yourself even when nobody supplies it, because the sheet you drew is the one you can read at speed in a dark room.

Whose rig is it?

A house rig belongs to the venue: fixed positions, a known patch, and rules about what may be moved. A touring rig arrives in trucks with its own plot, its own crew and its own show file. A one-off is hired in and built for a day.

What you are allowed to change depends entirely on which of the three you are standing in. On a house rig, ask before re-patching anything; on a touring rig, the visiting crew's file is the truth.

The cue synopsis

A cue synopsis lists the moments a show needs light to change — the script pages, the songs, the speaker changes — with a short description of each. It is written by the designer before the tech and is what the cues are built against.

For an operator it is a map of the evening: how many cues there are, where the fast ones are, and where a mistake would be most visible.

The documents an operator works from

Each answers a different question; none replaces another.

How to do it

1. Get the plot, the hookup and the cue synopsis, and check their revisions.
2. Walk the rig and compare it with the plot, position by position.
3. Note every difference: missing units, substituted types, changed positions.
4. Find out whose rig it is and what you may change.
5. Patch from the hookup, not from what you expect.
6. Prove the patch fixture by fixture.
7. Draw yourself a magic sheet before the designer arrives.
8. Report the differences to the designer or production electrician early.

What goes wrong

Practice it

Find any light plot — yours, a venue's, or a published one.

Patching Fixtures

Patching is the desk being introduced to the rig, fixture by fixture. It is clerical work that decides everything afterwards: get it right and the show behaves; get it wrong and you will spend the tech chasing ghosts.

Before you can control a light, the console has to know it's there.

What patching does

Patching is introducing the console to the fixtures: telling it what kind of fixture is at which DMX address, so it knows how to control each one. Remember from Lighting Basics that each fixture has a DMX address and uses a number of channels for its parameters; patching is where you tell the console at the desk side that, say, a particular moving head is patched at address 1 and is a certain fixture type. Once patched, the console knows that fixture's controls (intensity, colour, pan, tilt) and lets you operate them. Patching is the essential first step — an unpatched fixture is invisible to the console.

Patching in the console must match the addressing on the actual fixtures (the patch-and-address handshake from Lighting Basics). If a fixture is physically addressed at 1 but the console is patched expecting it at a different address, control will not work correctly. Getting the patch right — every fixture correctly typed and addressed in the console to match the rig — is the foundation everything else builds on, and a patch error is a common reason a light does the wrong thing.

For each fixture the desk needs three things: what it is, where it starts, and which universe it lives in. From the fixture type it knows how many channels the light uses and what each one does, so that a colour wheel is a colour wheel rather than channel seven.

The address on the desk must match the address set on the fixture itself. That handshake is the whole of patching, and the commonest fault in lighting is that the two no longer agree.

Organising the patch

A good patch is organised so the rig is easy to work with: fixtures grouped and labelled logically (all the front wash together, the moving heads together), so you can select and control them sensibly while programming. On a large rig with many fixtures, a clear, well-organised patch is what makes programming manageable rather than chaotic. The operator sets up the patch to reflect the rig in a way that makes the creative work that follows efficient.

Patching is also where you confirm the console and rig agree: after patching, you check that controlling each patched fixture actually affects the right real light (often by bringing each up one at a time). This verification — that the patch matches reality — catches addressing and patch errors before they cause confusion in programming or the show. A verified, organised patch is the solid foundation that makes the rest of lighting operation work smoothly.

Number by meaning. Front light in one block, backlight in another, moving lights in their own range, specials at the end. Leave gaps so that the unit added tomorrow does not have to go at the end of everything.

Label every fixture with what it is and where it is, not with its model number. "SL Wash 3" is useful in a dark room at ten o'clock; "Fixture 47" is not.

Profiles, personalities and modes

A profile — also called a personality or a fixture library entry — is the desk's description of a model of light: its channels, its ranges, its default values. Many fixtures offer several modes with different channel counts, and the mode on the fixture and the mode in the patch have to be the same one.

A wrong profile is worse than no profile: the fixture responds, but colour changes the gobo and dimming moves the head. When a light behaves nonsensically, check the mode before you suspect the light.

Universes, and running out of them

A DMX universe carries 512 channels. A simple LED wash may take four of them and a big moving light forty or more, so a modern rig fills universes quickly and is spread over several, carried to the rig by nodes over a network.

Plan where universes break before patching rather than after. Keeping a type of fixture, or a position, inside one universe makes fault-finding far easier later.

Proving the patch

Walk the rig with the desk. Bring up one channel at a time and confirm that the light that comes on is the one the desk says. This is the channel check, and it is the only thing that proves patch, addressing, data and the fixture itself all agree.

Do it before anything is programmed. An error found during a channel check costs a minute; the same error found in a tech rehearsal costs everybody in the room ten.

When the patch and the rig disagree

• Nothing happens: data, power, or the fixture is addressed elsewhere.
• The wrong light comes on: an addressing error, on the desk or on the fixture.
• Two lights come on together: two fixtures share an address.
• The light responds oddly: wrong profile or wrong mode.
• Only the first few channels work: the fixture is in a smaller mode than the patch expects.

What to check when a patched fixture does nothing

In this order. Most faults are found in the first three.

How to do it

1. Work from the hookup, in channel order.
2. Select the correct profile and the correct mode for each fixture.
3. Assign addresses and universes as the hookup specifies.
4. Label every fixture by position and purpose.
5. Leave numbering gaps for additions.
6. Channel check the whole rig, one fixture at a time, with somebody watching the stage.
7. Note every disagreement and fix it at the fixture or on the desk.
8. Save the file before programming anything.

What goes wrong

Practice it

On any desk, real or offline, patch a small rig.

Data, Networks and Addressing

Most calls of "that light is broken" are a data problem. Control leaves the desk as a stream of numbers and has to reach every fixture intact; where it does not, the fixture is innocent and the cable, the splitter or the network is guilty.

What DMX actually is

DMX carries 512 numbered slots, each holding a value, sent repeatedly and in order down a single cable run. Every fixture on that run hears all of it and pays attention only to the slots starting at its own address. There is no acknowledgement and no error correction: whatever arrives is acted on.

That simplicity is why it is everywhere and why it fails quietly. A corrupted stream does not report anything; it just makes a fixture behave strangely.

Cabling, topology and termination

A DMX run is a daisy chain: desk or node to fixture, fixture to fixture, with a terminator at the far end. It is not a star, it does not branch without a splitter, and it is not microphone cable — proper data cable matters on long runs.

Termination is a small resistor in a plug at the end of the chain. Its absence usually works and sometimes does not, which makes missing terminators one of the most maddening intermittent faults in the trade.

Splitters, nodes and universes on a network

A splitter takes one DMX line and drives several isolated branches, which both extends the rig and stops one bad fixture killing a whole run. A node converts between network protocols and physical DMX lines, so universes travel over a standard network cable and become DMX at the rig.

sACN and Art-Net are the two common ways of carrying universes over a network. Both work well on a properly configured, dedicated network and badly on a shared office one, which is why lighting networks are usually separate.

RDM, and addressing from the floor

RDM adds a back-channel to DMX: the desk can discover what is out there, read each fixture's address, mode, temperature and error state, and set its address remotely. On a rig hanging twelve metres up, that changes the day entirely.

It needs RDM-capable fixtures, splitters that pass it, and a controller that speaks it. Where any of those is missing the feature silently disappears, which is worth knowing before you plan an afternoon around it.

Faults that look like fixtures and are not

Flicker, random movement, one fixture stuck, a whole branch dead, everything fine until the smoke machine runs: all of these are data or power symptoms far more often than fixture failures.

Test by substitution and by isolation. Move the fixture to a known-good line; move a known-good fixture onto the suspect line. Two minutes of that answers the question that an hour of staring at a rig will not.

Data symptoms and their usual causes

Innocent fixtures are blamed for most of these.

On the job

Four fixtures at the end of a truss flicker during the show and are fine in the morning. The cause is a missing terminator that mattered only once the run was extended for the second act. A one-pound plug, half an hour of confusion, and a visible fault in front of an audience.

What goes wrong

Practice it

With any small rig you can reach.

Building Looks

A look is the rig doing something specific at a moment: these fixtures, at these intensities, in these colours, pointed here. Building looks quickly is the whole skill of programming, and the speed comes from work done before any look is built at all.

Lighting is painting with light — and the console is the brush.

Selecting fixtures and setting parameters

Building a look means creating a lighting state — a picture made of light. You do it by selecting the fixtures you want and setting their parameters: intensity (how bright), colour, beam, and position (the four properties from Lighting Basics). Select the front wash and bring it up warm; select the moving heads and set them blue, aimed at the stage. Each adjustment shapes the look until you have the picture you want. This is the creative heart of lighting operation — using the console to paint a scene with light.

The console gives you tools to do this efficiently: selecting groups of fixtures at once, setting parameters quickly, and adjusting by feel until the look is right. The skill blends the technical (knowing how to drive the console to set parameters) and the artistic (knowing what look serves the moment). Building looks well is what separates a lighting operator from someone just turning lights on — it is composing with light, fixture by fixture, parameter by parameter.

Every fixture is a set of parameters. Intensity is how bright, colour is what colour, beam covers gobo, zoom, focus, iris, prism and shutter, and position is pan and tilt. A look is a value for every parameter you care about.

Select, then set. Almost every desk works that way: choose the fixtures, then change the attribute. Getting fast at selection is worth more than getting fast at anything else.

From look to cue

Once you have built a look you like, you record it as a cue — storing that complete lighting state so it can be played back exactly later. Recording a cue captures all the fixtures' settings as a saved moment, often with a time (a fade) attached, so it can be recalled on command during the show (the cue concept from Lighting Basics, now created by you). This is how a look you build in programming becomes a repeatable part of the show. Build the look, record it as a cue, and you have made one moment of the show.

Programming a show is largely this: building look after look and recording each as a cue, until you have all the moments the show needs. Each cue is a saved picture of light; the show is the sequence of them. The operator works through the show building and recording cues in advance, so that on the night the show is a matter of playing them back. This build-and-record loop is the core programming activity of lighting operation.

When the look is right, record it. What gets recorded depends on the desk and on what you tell it: everything on stage, only what you have touched, only selected fixtures. Knowing which of those you are doing is the difference between a clean show file and a haunted one.

Name cues as you record them. "Cue 12" tells you nothing at half past ten on a Friday; "12 — band up, blue wash" tells you everything.

Groups first, always

Before any programming, build groups: all the front wash, all the backlight, the moving heads, odds and evens, stage left and stage right, each colour of LED bar. Building thirty groups takes twenty minutes and saves that in the first hour of a tech.

Groups are also how a designer's language reaches the desk. When they say "just the back trusses at fifty", that should be two presses, not a hunt through a patch.

Palettes, and why a show is built on them

A palette — also called a preset or a focus — stores a value for one kind of attribute: a colour palette for a particular red, a position palette for the downstage vocal spot, a beam palette for a narrow gobo look. Cues then refer to the palette rather than to raw numbers.

This is what makes a show survivable. When the rig moves, or the singer stands a metre left, you update one position palette and every cue that used it follows. A show programmed in raw values has to be rebuilt cue by cue.

Building looks that survive a change

• Use groups for selection, so a re-patched fixture stays inside its group.
• Use palettes for colour, beam and position, so one update fixes every cue.
• Record only what you mean to record.
• Name everything as you go, not afterwards.
• Save the file after every significant block of work.

Working quickly without making a mess

Speed in programming is mostly preparation and habit: groups and palettes built first, a magic sheet in front of you, a consistent naming scheme, and one way of recording that you use every time.

The programmers who look fastest are rarely pressing buttons faster. They are selecting in one move what others select in six.

What to build before the designer sits down

An hour here saves several during the tech.

How to do it

1. Build groups for every way you will need to select the rig.
2. Build colour palettes for the show's principal colours.
3. Build position palettes for the places performers will be.
4. Build beam palettes for the looks the designer has described.
5. Name every group and palette in plain language.
6. Draw or print a magic sheet that matches those names.
7. Save the file, and save a copy as the base state.
8. Only now start building looks.

What goes wrong

Practice it

On a desk or offline editor with a dozen fixtures patched.

Cues, Cue Stacks & Playback

A cue is a moment the desk can return to. A stack is those moments in order. Between them sits the one idea that confuses every newcomer on a modern desk: whether a change you make now stays changed for the rest of the show.

A show is a sequence of cues, run one GO at a time.

The cue stack

A cue stack (or cue list) is the ordered sequence of cues that makes up a show, arranged in the order they will be played. Once you have programmed your cues, you sequence them into the stack so that advancing through it runs the show in order. Each cue has its look and its timing (how it fades in), so moving from one cue to the next transitions the lighting smoothly from one state to the next. The cue stack is the show, written as a series of lighting states the operator steps through.

Building the cue stack means getting the cues in the right order with the right fade times, so the show flows as intended. This is the same cue-list discipline from media servers and playback, applied to lighting. A well-built cue stack means running the show is simply advancing through it; a disorganised one makes the live show a scramble. The operator prepares the stack carefully so the live operation is calm and reliable.

The stack is the show, in order, with a number for each cue so that cues can be inserted between existing ones — 12.5 between 12 and 13 — without renumbering anything. That habit alone saves hours in a tech.

Leave whole numbers for the show's real moments and use decimals for what gets added during rehearsal. When the numbering stops meaning anything, the stack is harder to talk about in a room.

Running on GO

Running a lighting show from a cue stack is done with GO: each press of the GO button executes the next cue, fading the lights from the current state to the next over the programmed time. The operator advances through the cue stack on the show's cues — pressing GO at each moment, often on the call of a stage manager or to the beat of the show — and the lights transition exactly as programmed. This is playback: the prepared cues running on command, turning the programming into a live lighting show. It is the lighting equivalent of the GO-driven cue lists used across the rest of the production.

Running the show well means hitting each GO at the right moment, in step with the show — the same standby-then-go timing discipline as other cued roles. The operator follows the show, stays ready for each cue, and fires it on time so the lighting lands with the music, the speaker, or the action. A well-programmed cue stack run with good timing produces a seamless lighting show that the audience experiences as part of the moment, never noticing the operator stepping through cues.

In playback, the desk is waiting on your GO. Alongside it sit back, which restores the previous state, and a way of jumping to a specific cue — the control you will want when a show skips a scene and nobody warned you.

Keep a hand near GO and your eyes on the stage. The cue you are about to fire is written down; what is happening on stage is not.

Tracking, cue only and blocks

On a tracking desk, a value you set stays set in every following cue until something changes it. Record a blue wash in cue 5 and it is still there in cue 9 unless cue 6, 7 or 8 says otherwise. That is a feature: you record only what changes.

Cue only records a change into one cue and leaves the following cue as it was. A block cue deliberately stops values tracking through it, so that a change made earlier cannot leak into the second act. Knowing which mode you are in when you press record is the single most useful piece of console literacy there is.

Cue timing

Every cue has a time: how long the fade takes. Most desks add a delay (wait before starting), a wait or follow (fire the next cue automatically after this one), and parts, which let different fixtures in the same cue move at different speeds.

Timing is where a cue stops being correct and starts being right. A three-second fade and a three-minute fade are the same cue with entirely different meanings, and the designer will ask for both.

Updating cues in rehearsal

Most of a tech is changing what already exists. Make the change, decide whether it belongs in this cue only or from here onwards, and update. Say out loud what you have done — "that's in cue 14 only" — so the designer knows what they are looking at.

Save often and save named versions at the end of each session. A tech is exactly the situation in which somebody presses the wrong thing, and a file from an hour ago is a far better answer than an evening of work.

What to do when a cue goes wrong live

Keep going. A wrong state held confidently is far less noticeable than a desk being fiddled with. Fix it at the next natural cue rather than reaching for the fault in the middle of a moment.

If you fire a cue early, do not fire back into it in a panic. Note where the stack now is, ride it out, and rejoin at the next cue the stage manager calls.

Recording modes, and what each one does

Say which one you are using before you press record.

How to do it

1. Record the opening state as cue 1 with a sensible time.
2. Work in the order the show happens, not the order that is convenient.
3. Record each change as it is agreed, saying aloud what you recorded.
4. Use decimals for cues inserted between existing ones.
5. Give every cue a name that means something at speed.
6. Set times as they are asked for; note the ones that are still guesses.
7. Put block cues at act starts so nothing tracks across an interval.
8. Save a named version at the end of every session.

What goes wrong

Practice it

On a desk or offline editor, build a ten-cue stack.

Faders, Effects and Everything That Is Not GO

A cue stack is one way of playing a rig back, and on many shows it is not the main one. Faders hold states, executors hold chases, effects generate movement nobody recorded frame by frame, and macros do in one press what would take twenty.

Faders, submasters and executors

A submaster or executor is a fader or button holding something — a group at a level, a colour state, a chase, a whole look — that can be brought in on top of or instead of the stack. On concert desks these are the show; on theatre desks they are the extras.

Lay them out so that your hands know where things are without looking. Colours in one row, positions in another, effects in a third, and the same layout every time you build a file.

Highest takes precedence, and what overrides what

When two sources want the same parameter, the desk needs a rule. For intensity it is usually highest takes precedence: whichever source asks for the most wins. For attributes such as colour and position it is usually latest takes precedence: the most recent instruction wins.

This is why a forgotten submaster at ten per cent can quietly light a blackout, and why a busked colour can refuse to go away. When something will not turn off, ask what else is asking for it.

Effects, chases and shapes

An effect engine generates movement mathematically: a circle on pan and tilt, a sine on intensity, a colour step through a palette, with a size, a speed and an offset between fixtures. A chase steps through recorded states in order at a set rate.

The offset is what makes an effect look designed rather than mechanical: the same circle, spread across twelve fixtures, becomes a wave. Speed is almost always the control the designer will want on a fader.

Macros and command-line habits

A macro records a sequence of presses so it can be repeated in one. Useful macros are the boring ones: clear the programmer, release everything, go to a known state, black out safely, set a house preset.

On command-line desks, learn the small vocabulary that does most of the work — select, at, record, update, copy, delete, time — and the rest of the desk becomes shortcuts to things you can already say.

Building a layout you can play

For a busked show the layout is the instrument. Decide what each fader does, keep the arrangement consistent between shows, and leave the most used things under your strongest hand.

Label the layout physically as well as on screen where you can. In the dark, a strip of tape with three words on it beats a menu.

What lives on a playback, and what it is for

A well-built layout is why some operators look effortless.

On the job

A blackout is not black. Two fixtures sit at eight per cent, and the cause is a submaster nudged an hour earlier that nobody noticed. The operator who knows that intensity is highest-takes-precedence finds it in five seconds; everybody else looks at the patch.

What goes wrong

Practice it

On a desk with a dozen fixtures.

Focus Sessions and Tech Rehearsals

The two days that decide a lighting show are the focus session, when the rig is aimed, and the technical rehearsal, when the show is built. Both are done with other people waiting, and both reward preparation far more than talent.

The focus session

Focusing is aiming: each fixture is brought up alone, somebody stands where the light is wanted, and the unit is panned, tilted, shuttered, zoomed and locked off. The designer calls it; an electrician on a ladder or lift does it; the operator drives the desk and writes it down.

Work in an order that suits the rig rather than the plot — one position at a time, one lift move at a time — because moving the access equipment is what costs the day.

Focus notes, and why they are gold

A focus note records what each unit was focused to: the area, the person, the mark, and any shuttering. Written during the session, they let the rig be re-focused in a new venue, or re-aimed after something is knocked, without the designer being present.

On moving lights, the equivalent is the position palette. Record one for every place the show uses, name it for the place rather than the number, and the show can be re-pointed anywhere.

The technical rehearsal

A tech is where the show is assembled: the company works through the piece, stopping to build each moment, while lighting, sound, video and stage management record what they need. It is slow, it is public, and everybody's attention is on whoever is holding it up.

The operator's job is to be never the reason for the pause. That means groups and palettes built, a magic sheet to hand, one consistent way of recording, and saying clearly what you have just done.

Working with a designer

A designer thinks in looks and asks in shorthand: warmer, tighter, take the sides out, lose the backlight, make it later in the day. Your job is to translate that into the desk quickly and without editorial.

Offer options rather than opinions. "Do you want that in the cue only, or from here on?" is useful; "I think the blue is better" usually is not, unless you are asked.

Being called by a stage manager

In theatre, the operator does not decide when a cue happens. The stage manager calls standby — "standby LX 47" — and you acknowledge; then they call go and you press. Nothing else.

Acknowledge every standby, never anticipate a go, and if you miss one, say so on comms immediately and take the next call. The calling system only works if everybody in it is honest in real time.

Notes sessions and turning them round

After each run there is a notes session: a list of changes, given fast. Write them all down first and question none of them until the list is complete; half the notes solve each other.

Then work through them in stack order rather than in the order they were given, so the file is touched once per cue rather than five times.

What to have ready before a tech starts

Everything here is preparation nobody will give you time for later.

How to do it

1. Bring up a single fixture at a workable level and nothing else.
2. Call out which unit is live so the person on the lift knows.
3. Hold it while the designer directs the aim and the shutters.
4. Write the focus note as it is agreed, not afterwards.
5. For movers, record a position palette named for the place.
6. Park the unit and move to the next in the same position.
7. Keep a list of units that could not be reached or finished.
8. Save the file at the end of every position.

What goes wrong

Practice it

Whether or not you have a rig, run the process on paper.

Busking, Live Operation & Troubleshooting

Outside theatre, most lighting is played rather than run. There is no stack, no script and often no rehearsal: a band walks on, and somebody makes the rig match the music in real time. It looks like improvisation and it is almost entirely preparation.

Not every show is pre-programmed — and things still go wrong.

Busking and live operation

Not all lighting is run from a pre-built cue stack. Busking is operating lights live, building looks on the fly by feel — common for concerts and events where the lighting responds spontaneously to the music or the moment rather than following a fixed script. A busking operator uses the console's faders, buttons, and effects to control the rig live, reacting in real time, which is a different skill from running a programmed cue stack — more improvisational, like playing an instrument with the lights. Many shows blend the two: a cue stack for structured moments and live busking for flexible ones.

Both approaches use the same console fundamentals (patch, the fixtures, the parameters) but apply them differently — the cue stack is composed in advance, busking is performed live. Understanding both, and when each fits, makes you a versatile operator. A corporate show might run entirely on a cue stack for precision; a concert might be largely busked for energy and responsiveness. Knowing how to do both, and to combine them, is part of being a complete lighting operator.

Busking means building playback material in advance — colour states, position states, looks, chases with their speeds — laid out so that they can be combined live. The skill is in the layout and in knowing the music, not in fast fingers.

Watch the stage and listen. Changes land on musical events: a chorus, a drop, a solo, the end of a verse. A change that arrives slightly late looks like a mistake; one that arrives with the music looks like design.

Troubleshooting and growing

Lighting-console problems are diagnosed with the systematic method, often tracing back to Lighting Basics. A fixture not responding usually points to patch or addressing (does the console patch match the fixture's address?) or to data/power not reaching the fixture (the DMX-or-power check from Lighting Basics). A cue not looking right points to how it was programmed. The console misbehaving points to its settings or programming. Knowing the patch-program-playback structure and the underlying DMX lets you isolate where a problem lies — a console issue, a patch error, or a fixture/data/power problem out in the rig.

Because lighting runs live, calm methodical troubleshooting matters, and good preparation (a verified patch, tested cues, a rehearsed stack) means few live faults. Master patching, building looks, recording cues, running a cue stack, busking, and troubleshooting, and you can operate a lighting console for real shows — the bridge from lighting theory to lighting craft. From here, mastering specific consoles (like the grandMA or ETC platforms) and advanced programming deepens the specialty, but the operation fundamentals are the same across them all.

Fault-find in the same order every time: is it the desk, the data, the power, or the fixture? Prove the desk is sending, prove data arrives, prove the fixture has power, and only then suspect the light itself.

Do it quietly. Most of the room cannot tell the difference between a failure and an operator who has not noticed, but everybody can see a person panicking at a console.

Practical sign-off

Lighting operation is learned on a real console. The learner patches fixtures, builds looks, records cues, runs a cue stack on GO, tries busking, and troubleshoots a fault. A mentor signs off when the learner can program and run lights for a small show.

• Patched and verified fixtures on a console
• Built looks by setting fixture parameters
• Recorded cues and sequenced a cue stack
• Ran the show on GO and troubleshot a fixture/patch fault

Preparing to busk a band you have never heard

Ask for a set list and mark it: which songs are fast, which are ballads, where the solos are, where the singer talks. Ask the tour manager if any song has a specific look. Build four or five states you can live in — a warm, a cold, a big, a small and a bare one — and a way out of all of them.

Keep intensity under your hand. If in doubt, less: a simple look held through a song is better than a rig thrashing at every bar.

Support acts, corporate and one-offs

Support acts get whatever is left of the headliner's rig and ten minutes of your attention. Give them something clean, do not touch the headliner's file and put back anything you changed.

Corporate work is busking with different rules: the speaker must be lit properly, the brand colours are usually specified, and the mood changes at the presenter's instruction rather than at a chorus. Clean, bright, unfussy — and never dark on somebody's face.

The questions, in order

• Is the desk actually outputting — is the fixture parked, released or at zero?
• Is data reaching it — what does the fixture's own indicator say?
• Does it have power, and has it homed properly?
• Is the address or mode right on the fixture and on the desk?
• Only then: is the fixture itself broken?

Recovering in front of an audience

If a fixture fails mid-show, take it out of the look rather than leaving a hole where it was. If a cue is wrong, hold it and fix it at the next natural change. If the desk fails entirely, get light on the stage by whatever means exist, and worry about the show afterwards.

Have a plan for the worst case before doors: what you would do if the desk restarted mid-show, and where the house lights are controlled from. Ten seconds of thinking in the afternoon is the difference between a pause and a disaster.

Fault-finding order, and what each test proves

Work down the list. Do not skip to the interesting answer.

How to do it

1. Get the set list and mark tempo, mood and features against each song.
2. Build five states you can hold a song in, and put them on faders.
3. Build a colour row and a position row you can combine with them.
4. Build one chase with its speed on a fader.
5. Set a bare state and a blackout you can reach without looking.
6. Watch the first song and do almost nothing.
7. Change on musical events, not between them.
8. Save anything that worked before the next show.

What goes wrong

Practice it

Busk one song, on any rig, with a recording you know.

Timecode and Show Control

Sooner or later the lighting stack stops being driven by a person. A timecode stream, a show controller, a video server or a sound desk takes over, and the operator's job becomes making sure the desk is listening and knows what to do when the signal stops.

Why anything triggers anything

When several departments must hit the same moment — a video frame, a lighting change, a pyrotechnic, an audio stinger — a human in each department pressing GO is not accurate enough. One clock, or one controller, fires them all.

That clock is usually timecode: a running count of hours, minutes, seconds and frames, distributed to every department, with each desk holding a list of what to do at which time.

Timecode in practice

The desk receives timecode and each cue in the stack carries a trigger time. When the incoming clock reaches that time, the cue fires. Programming is done by playing the track, marking times roughly, then nudging them frame by frame until they land.

Know what happens when timecode stops: most desks can hold, jump or continue, and the right behaviour depends on the show. Know too how to take manual control instantly, because the day the clock dies you will need to run the show by hand.

MIDI, OSC and contact closures

MIDI notes and MIDI show control, OSC messages over a network, and simple contact closures all do the same job at smaller scale: one device telling another that a moment has arrived.

They are the glue of corporate and installed work — a button on a wall, a cue from a presentation system, a trigger from a media server — and they are worth understanding even if somebody else configures them.

Working inside somebody else's show control

When a show controller is in charge, your stack is a set of states it can call, and the numbering becomes an interface between departments. Do not renumber cues without telling whoever holds the master list.

Agree early what happens on a restart: where the show picks up, what state the rig should be in, and who decides. Most show-control disasters are recovery problems, not trigger problems.

Rehearsing the failure

Before the show, rehearse losing the trigger. Stop the timecode mid-run and take the stack manually. Restart it and watch where the desk goes. Do it once in the afternoon so that when it happens at night you have already done it.

Write the manual fallback down on the same sheet as the cue list, because the moment you need it is the moment you will not be thinking clearly.

Ways one thing triggers another

All of them do the same job at different scales.

On the job

A corporate opening runs to timecode with video, lighting and audio locked together. The playback laptop drops the stream twelve seconds in. The lighting operator, who rehearsed this in the afternoon, takes the stack manually at the next cue and the room never notices.

What goes wrong

Practice it

With any desk that accepts timecode, or with MIDI from a laptop.

Moving Lights, LEDs and Colour

A modern rig is mostly motors and diodes. Both behave in ways a lamp never did: they home, they calibrate, they mix colour arithmetically, they dim on a curve somebody chose, and they can look perfect to your eye and terrible on camera.

What a moving light is doing

A moving head contains a source, a colour system, a beam system and two motors for pan and tilt, all under the control of a small computer. When it powers up it homes: it drives each mechanism to a known end stop so it knows where everything is.

If a fixture is in the wrong place, is a different colour from its neighbours, or has a gobo halfway in, the first move is usually a reset: tell it to home again from the desk and let it re-find itself.

Colour mixing systems

Subtractive mixing takes white light and removes what you do not want, using cyan, magenta and yellow flags — the CMY system in most moving lights. Additive mixing builds colour by combining coloured emitters, which is what LED fixtures do with red, green, blue and often white, amber or lime.

The practical difference is what happens at the edges. Subtractive systems dim colour smoothly and lose output as they saturate; additive systems can make some colours brilliantly and others not at all, and two fixtures of different models rarely match without being tweaked.

Making a rig match

Different models, different ages and different production batches do not produce the same white or the same red. Build the palette from the fixture that looks worst, then trim the others to it, and store the result as a palette per fixture type.

Do this once at the start, and every cue afterwards inherits it. Do it never, and the audience sees a row of nearly-matching lights all night.

Dimming curves and the bottom end

A dimming curve maps the control value to actual output. Tungsten fixtures dim gently and warm as they go; LEDs dim linearly unless told otherwise, and often step or extinguish in the last few per cent.

Where a desk or fixture offers curves, choose one deliberately and use the same one across the rig. A slow fade to black that ends in a visible snap is almost always a bottom-end curve problem.

LED on camera

LEDs are dimmed by switching very fast, and cameras sample at their own rate. When the two disagree you get banding, flicker or rolling bars in footage that looked perfect to the eye in the room.

Where anything is being filmed, ask the camera department early, use fixtures with a selectable high refresh rate, set it, and then look at an actual camera before the audience arrives. This problem is invisible from the desk.

Haze, and why beams need air

A beam is only visible because of particles in the air. Haze is a fine, even suspension that reveals beams without looking like smoke; smoke and fog are heavier effects for a deliberate look.

Haze takes time to fill a room and needs the air handling turned down to stay. It also sets off smoke detection systems, which is a conversation with the venue and sometimes with a fire officer, held well before the show.

A fixture misbehaving, and what it usually means

Reset first; most of these clear themselves.

How to do it

1. Power up and let every fixture finish homing before touching anything.
2. Check that all units of a type report the same mode.
3. Bring the whole type up in open white and compare.
4. Trim each unit to the worst one, not to the best.
5. Store a matched white palette for that type.
6. Repeat for the show's main colours.
7. Set the same dimming curve across the rig.
8. If cameras are present, look at a camera before you call it done.

What goes wrong

Practice it

With any group of LED or moving fixtures.

Power, Safety and the Rig Overhead

A lighting rig is an electrical installation hanging over people's heads, running hot. The operator does not rig it and does not wire it, and still has to understand it — because the operator is often the person who notices first that something is wrong.

What a rig draws

Every fixture has a power figure, and a rig's total is what the venue has to supply. LED fixtures draw far less than the tungsten they replaced, but they draw it all the time rather than only when bright, and a truss full of them still adds up.

Power is distributed from a board through cable to the rig, and the distribution is designed by somebody qualified. What an operator needs is the total, the circuits, and the knowledge of which fixtures are on which circuit when one goes out.

Fixtures overhead

Anything hung over people carries a primary fixing and a secondary safety — a bond or wire that holds the unit if the clamp fails. Accessories such as barn doors and gobo holders get their own safeties, because they are what actually falls.

Nobody works under a rig that is moving, and nobody stands under a fixture being worked on. As an operator, keep the stage clear when units are being focused and never bring a mover to life while somebody's hands are in it.

Heat and hands

Fixtures get hot — hot enough to burn instantly, and they stay hot long after they are switched off. Gel frames, barn doors and the bodies of tungsten units are all burns waiting to happen, and gloves live in a technician's back pocket for exactly this.

Heat also matters to the things around a fixture: drapes, scenery, sprinkler heads and ceilings all have minimum distances, and fixtures near them are somebody's documented decision, not an accident.

Working around a rig safely

• Keep the floor clear under anything being rigged, focused or serviced.
• Never park a mover in a position where somebody is working on it.
• Warn the floor before any rig movement, and wait for the acknowledgement.
• Treat every fixture as hot unless you know it is not.
• Report damaged clamps, missing safeties and frayed cable immediately, in writing.
• Stop work that is unsafe, and say why; nobody in this industry is fired for that.

Haze, alarms and the venue

Atmospheric effects and smoke detection do not get along. Venues have procedures: detectors isolated for the performance, a fire watch in place, an agreed limit, and a person responsible.

As an operator you may be asked to run the hazer. Know who agreed what, know how to stop it instantly, and never start hazing because the beams look better without telling anybody.

What an operator must recognise, even though somebody else does it

Recognising these is the operator's part of rig safety.

On the job

An operator notices during a channel check that one fixture has no safety bond. It takes one radio call and five minutes to fix at four in the afternoon. The same observation at ten at night, with an audience underneath it, has no good answer.

What goes wrong

Practice it

At the next rig you stand under.

Show Files, Load-out and Where This Leads

A show file is days of work in something the size of a photograph, on a machine that will eventually fail. How you save it, where you put it and what you leave behind at the end of a job is the difference between a craft and a series of heroic rescues.

Saving, naming and versions

Save at every natural break and name versions by date and stage: after patch, after palettes, after the first act, after notes. A file called show_final_3 tells you nothing; one called 2026-09-17 after tech notes tells you everything.

Keep the old versions. The whole point of a named history is being able to go back one step when something has been overwritten, and the step you will want is never the one you expected.

Backups, off the desk

Export the file from the console to a memory stick, and get a second copy somewhere that is not in the same case: a laptop, a cloud folder, a colleague's stick. Consoles fail, sticks fail, and cases get left behind.

Where a production runs a tracking backup — a second desk following the first, ready to take over — know how it is armed, how you hand over to it, and test the handover before the audience arrives rather than during.

Load-out, and what the next show inherits

At the end, the rig is either struck or handed on. Either way: put house fixtures back where they were, restore any patch you changed, coil and label what you used, flag anything broken, and leave the desk in the state the venue expects to find it.

Write the handover note even when nobody asked for one: what you changed, what is broken, where the file is. The next operator is often you, six months later, with no memory of any of it.

Where lighting operation leads

From operating, the routes are clear: programmer, building shows for designers at scale; lighting designer, deciding what the show looks like; system or crew chief, owning the rig and the data; production electrician, owning the plot, power and paperwork; and the touring versions of all of them.

Every one of those jobs is built on doing this one well. Nobody is hired to programme a large show by somebody who has not first proved they can patch a rig, keep a file tidy and stay calm through a tech.

How to get better, deliberately

• Rebuild a show you have run, from scratch, on an offline editor.
• Programme the same look three ways and keep the fastest.
• Learn one new desk a year well enough to patch and busk on it.
• Watch other operators' hands during changeovers.
• Keep your own template file: groups, palettes, layout, macros, ready to adapt.
• Ask designers what they wish operators did differently, and believe the answer.

Where operating leads, and what each role adds

All of them are built on the same foundation.

How to do it

1. Save the final show file and name it with the date and the production.
2. Export it to two places, one of them not in the console case.
3. Restore any house patch or house preset you changed.
4. Return borrowed fixtures, cable and accessories to where they came from.
5. Flag and label anything broken, in writing.
6. Leave the desk in the state the venue expects.
7. Write a short handover note: changes, faults, and where the file is.
8. Keep your own copy of the file for your template library.

What goes wrong

Practice it

Take the next show file you build.

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