Lighting Intermediate

Introduction

There is a moment that separates operators from programmers. You have a rig, a designer beside you, and they say "can we see that again but warmer, and can the back light come up a beat later". If you know your desk, that is nine seconds of work. If you do not, it is four minutes of hunting, and by the fourth time it happens the session has changed character -- the designer has started asking for less, because asking costs too much.

That is what this book is about. Not what the light should do, which is Lighting Design's subject, and not what is inside the fixture, which is Lighting Automation's. This is about the machine between them, and the craft of making it answer quickly.

What this book covers

The programmer, and why every desk has one. Selecting fixtures, and why the order you selected in decides what every later tool does. Groups. Palettes and presets, and the four families they come in. Tracking against cue-only, which is the idea that surprises every operator moving up. Blocking. Update, and its styles. Timing, discrete timing and multipart cues. Mark, and moving a light while nobody is watching. Effects engines, and the rate, size and offset that turn one effect into a hundred. Fanning. Highlight, Lowlight and Rem Dim. Playbacks, submasters and busking. Building the views, direct selects and magic sheet you work from. Macros. Patch beyond the basics -- profiles, attributes, moving show data. Show files, versions and naming. Pre-programming and working blind. Working with a designer in the room. Adapting a file to a rig that is not the one you programmed for. And safety, at a desk you cannot see the stage from.

It was measured against the published course outlines that ETC and MA Lighting put out for their own consoles, and against the twenty-seven-chapter contents of Moody and Dexter's Concert Lighting, so that nothing those teach a working programmer is missing here.

Why two manufacturers

Because this is a book about programming, not a manual for one desk. ETC's Eos family and MA Lighting's grandMA are the two consoles you are most likely to meet, and they name almost everything differently.

Where the two agree -- the programmer, groups, palettes and presets, sequences and tracking, effects -- the idea is the craft, and it will be true of the next desk you sit at too. Where they differ, that is the brand, and it is worth knowing which is which before you decide you cannot use an unfamiliar console.

Who this is for

Anyone who can run a lighting rig and has started to be asked to build one. Board operators being handed cueing sessions, technicians who have inherited a show file, and house staff who keep having to adapt somebody else's programming to their room.

This Book Does Not Replace Your Console's Manual

Every desk names these things differently, and some of them work differently underneath. What one calls a palette another calls a preset. What one calls a cue list another calls a sequence. Mark is Mark on one desk and something else entirely on the next.

So this book teaches the ideas and names them in both vocabularies where they differ. The syntax that matters is the one in front of you, and the manual for your own console is the document that has it.

What this gives you is the thing a manual cannot: knowing what to look up. A manual answers "how do I block a cue on this desk". It does not tell you that a change running away through forty cues is what blocking is for.

How to Use This Book

Read the first seven chapters in order and do not skip them. The programmer, selection order, groups, palettes and tracking are the five ideas everything else is built on, and every later chapter assumes them.

Get on a desk

Reading about programming is not programming. Both major manufacturers publish free offline software that runs on an ordinary laptop and behaves like the real console. There is no excuse and no cost, and an hour a day on offline software for a fortnight will change what you can do.

Keep a notebook

Write down the syntax you had to look up. You will look it up three times before it sticks, and the third time is faster if you wrote it the first time.

Write down what each show file taught you. Every inherited file has one good idea in it and one thing that was done the hard way, and noticing both is how programmers get better.

A note on the words

A channel is a fixture as the console counts it. An address is where it lives in DMX. A parameter is anything a fixture can do -- intensity is one, pan is another. A palette or preset is a stored value you refer to rather than copy. A cue or sequence step is a recorded state. Tracking means a value stays set until something changes it.

The words that cause the most trouble are "record", which on most desks means store, and "update", which means put this change back into something that already exists. Confusing them is how people overwrite a show.

A note on safety

You will be moving fixtures over people's heads from a desk you cannot always see the stage from. That is a real hazard and it has a simple discipline, which is the chapter "Safety, and Where This Leads", and is worth reading before you first push a fader in a room with a crew in it.

From Operating to Programming

An operator runs what exists. A programmer decides what will exist. It is a change of job, not a promotion within one.

The unit of work changes

Operating is measured in cues taken -- the right thing happening at the right moment, every night, reliably. It is a performance skill and a real one.

Programming is measured in looks built and in how fast you can change one. Nobody watches you do it, the work happens before the audience arrives, and the thing you produce is a file.

What you are actually being paid for

Speed, mostly. A designer's ideas arrive faster than any desk can be driven, and the programmer's job is to be the narrowest possible bottleneck between an idea and seeing it on stage.

Which is why this book spends so much of its length on things that look like housekeeping -- groups, palettes, views, macros. They are not housekeeping. They are the difference between nine seconds and four minutes, forty times an hour.

The structure underneath

Every console has the same skeleton, whatever it calls the bones. A patch that says what exists. A programmer that holds what you are changing. References -- groups, palettes, presets -- that let you name things once. Recorded states, in lists that play back. And tools that generate movement rather than storing it.

Learn that skeleton and an unfamiliar desk becomes a vocabulary problem rather than a wall. That is the single most valuable thing in this book.

What does not change

Your judgement about light. A programmer who cannot see that a face is unlit is a fast typist, and every experienced designer has worked with one.

Keep looking at the stage rather than the screen. The desk is never the product.

Operating against programming

The skeleton every desk has

How to do it

1. Get offline software for the desk you will actually be sitting at.
2. Learn the skeleton first -- patch, programmer, references, cues, effects -- rather than learning buttons.
3. Rebuild a show you have run, from its paperwork, offline.
4. Time yourself making one change, then make the same change again using a reference instead of a hard value.
5. Keep looking at the stage rather than at the screen.

What goes wrong

Practice it

Offline software, and the paperwork from any show you have run.

Finding Your Way Round an Unfamiliar Desk

You will be handed a console you have never touched, with a show in four hours. This is the chapter for that afternoon.

The five questions

How do I select something. How do I set a value. How do I store it. How do I refer to something I stored. How do I clear what I am holding.

Answer those five and you can programme, badly but genuinely, on any desk in the world. Everything else in this book is refinement on top of them.

Command line against direct manipulation

Consoles divide into two philosophies. Some are command-line first -- you type a sentence, `Channel 5 through 9 at 50`, and press enter. Others are selection-first: you touch the fixtures, then turn an encoder, and the desk follows.

Most modern desks do both, and lean one way. Knowing which way yours leans tells you where to look for speed, because the fast path on a command-line desk is typing and the fast path on the other is a well-built layout.

Encoders, and the wheel problem

Every multi-parameter fixture has more parameters than the desk has physical wheels, so encoders are paged. The single most common cause of "this fixture will not do anything" is having the wrong page of encoders in front of you.

Find out how your desk shows which page you are on, and check it before you conclude a fixture is broken.

Reading the display before touching anything

Every desk colours its values to tell you where they came from -- set by hand, played back from a cue, referenced from a palette, tracked from an earlier cue. The colours differ; the categories do not.

Learn that colour key in the first ten minutes. It is the desk telling you the truth about your show, and people work for years without reading it.

What to find before the show, in order

Clear. Undo. Save. Then selection, values, record, and reference. Clear and undo come first because they are what let you explore safely, and save comes third because the first thing you will do is something you regret.

The five questions, in both vocabularies

What the value colours are telling you

How to do it

1. Find Clear, Undo and Save, and use each once.
2. Select one fixture and put it at full, any way that works.
3. Store that as a cue, then clear, then play it back.
4. Store a colour as a reference, then apply it to a different fixture.
5. Find the encoder paging and read the page indicator.
6. Read the colour key for values, from the manual if it is not obvious.
7. Only now start building anything you intend to keep.

What goes wrong

Practice it

Any console you do not know, real or offline.

The Programmer

The single idea that separates people who use a console from people who fight it. Almost every "why did that happen" question has this as its answer.

What it actually is

A staging area. When you select fixtures and change something, the change does not go into the show -- it goes into the programmer, a holding space that sits on top of everything else and wins.

Nothing you do there is permanent until you store it, and nothing else can override it while it is there. That is the whole mechanism, and both major desk families have it under different names.

Why it wins over everything

Deliberately. You need to be able to look at a fixture during a show without the show taking it back off you halfway through. So the programmer has the highest priority on the desk.

The consequence is the commonest beginner failure in lighting: you have values in the programmer, you play back a cue, and the cue appears not to work. It is working. You are holding those fixtures.

Clear, and why it is the most-pressed key

Clearing releases what you are holding and hands the fixtures back to the show. Experienced programmers clear constantly and almost unconsciously, between every operation.

On some desks one press clears the selection and a second clears the values, which is why you will see people hit it twice without thinking. Find out what yours does, because "I cleared it" and "I cleared it twice" are different states.

What is in there, and how to look

Every desk has a display that shows only what the programmer is holding. Learn where it is. It turns "why is this happening" from a mystery into a list you can read.

Before you record anything, look at that list and ask whether it is what you meant to store. Recording the contents of a programmer you have not looked at is how shows acquire values nobody can explain.

Recording takes from the programmer, not from the stage

This is worth saying plainly because it catches people. When you record a cue, most desks store what you are holding, not what the stage looks like.

So a beautiful stage picture made of a playback plus two programmer values may record as two values. Knowing which mode your desk records in -- and most offer a choice -- is the difference between storing a look and storing a fragment.

The programmer, in both vocabularies

What "it is not working" usually means

How to do it

1. Clear before you start anything new.
2. Select, then change, then look at the programmer display.
3. Ask whether what is held is what you mean to store.
4. Record.
5. Clear again, and confirm the stage still looks right from playback alone.

What goes wrong

Practice it

Any console, real or offline, with a few cues recorded.

Selecting, and Selection Order

The order you selected in is invisible, and it decides what fanning, effects and offsets do. This is the chapter people wish they had read first.

Selection is not a set, it is a list

When you select channels 1 through 8, the desk does not hold "these eight fixtures". It holds them in that order, first to last, and it remembers.

Select 8 through 1 instead and you have the same eight fixtures and a different list. Nothing on screen looks different. Every tool that spreads a value across a selection will behave in reverse.

What depends on it

Fanning spreads from the first of the selection to the last. Effects offset from first to last. Any tool that asks for a direction takes it from selection order, because that is the only order the desk has.

So a chase that runs the wrong way across the stage is almost never an effect problem. It is a selection problem, and the fix is to reselect rather than to fight the effect's settings.

Selecting in a useful order

Stage left to right is the usual default because that is how audiences read a stage and how designers describe it. Build your groups that way and most effects come out facing the right direction without thought.

For a rig that is not a line -- a circle of movers, two trusses, a grid -- the useful order is whatever produces the movement you want most often. Decide it once, build the group, and stop thinking about it.

Sub-selection, and working within a selection

Every desk lets you step through a selection one fixture at a time without losing it, which is how you check a wash unit by unit during focus without reselecting between each.

It is also how you set one fixture differently inside a group without breaking the group. Find the key for next and last on your desk in the first week.

Reselecting without retyping

Desks remember the previous selection and let you call it back. On a long session this saves more keystrokes than any other single habit, because you almost always want the thing you just had.

Learn it and use it. The measure of a fast programmer is rarely typing speed; it is how seldom they retype anything.

What takes its direction from selection order

Selection habits worth having

How to do it

1. Look at the chase and decide which fixture should start.
2. Clear, and reselect starting from that fixture.
3. Reapply the effect and check the direction.
4. If it is right, record the selection as a group so you never solve this twice.
5. If your rig has a habitual direction, build every group that way.

What goes wrong

Practice it

Eight fixtures in a row, real or offline, and any effect.

Groups

The first structure you build, and the one everything else hangs on. A rig without groups is a rig you address one fixture at a time, for ever.

What a group is for

Naming a set of fixtures once so you never have to remember which channels they are again. The front wash. The movers on the upstage truss. The cyc. The specials.

That sounds administrative. It is actually the difference between a session where the designer says "front wash" and you have it in half a second, and one where you are reading a hookup sheet.

What to build, and in what order

Build by system first -- the things a designer will ask for by name. Then by position, because focus and troubleshooting happen by position. Then the odd useful subsets: odds and evens, every third, the ones you can see from the desk.

Odds and evens deserve their own mention. Half a wash is the single most-used subset in the trade, because it is how you get a different look out of a rig you cannot add to.

Naming a group

A group called "Group 12" is a group nobody else can use, including you in three weeks. Name them the way the designer talks: FRONT WASH, BACK TRUSS MOVERS, CYC, HOT SPECIALS.

Use the show's own language rather than the rig's. If everybody calls the upstage bar "the ladder", call the group LADDER. You are building a vocabulary you will have to speak under pressure.

Numbering that survives

Leave gaps. Groups 1 to 10 for washes, 11 to 20 for movers, 21 upward for specials, and room after each block. The first time somebody adds four fixtures you will be glad you did not number consecutively.

Keep the numbering consistent across shows in the same venue if you can. House programmers who do this can walk into their own room and be useful in ten minutes rather than an hour.

Groups as the base for everything else

Palettes get recorded for groups. Effects get applied to groups. Submasters hold groups. A rig with good groups programmes itself quickly; a rig without them stays slow no matter how good the programmer is.

Which is why groups come before cues, always, on every show, including the ones where there is no time.

The groups worth building on every show

Naming, badly and well

How to do it

1. Get the plot, or walk the rig, and list the systems by the names people use for them.
2. Build a group per system, selecting stage left to right.
3. Build a group per position.
4. Build odds and evens for every wash.
5. Build all-movers, all-conventionals and everything.
6. Name every one in the show's own language, in capitals so they read at a glance.
7. Leave numbering gaps between the blocks.
8. Only now start building looks.

What goes wrong

Practice it

Any rig of a dozen fixtures or more, real or offline.

Palettes and Presets

A show built on references changes in one place. A show built on hard values changes in four hundred. This is the most valuable hour in the book.

The idea

Store a value once, give it a name, and have your cues refer to it rather than copy it. Then when the value has to change -- and it always does -- you change the reference and every cue that used it follows.

Both desk families do this. Eos calls them palettes and presets; grandMA calls them presets. The distinction between the two words differs by manufacturer and matters less than the habit.

The four families

Intensity, focus, colour and beam. They are kept apart on purpose so that a note about colour does not disturb a position, and a refocus does not change anybody's colour.

That separation is what lets a designer say "same look, different colour" and get it immediately. Store everything together in one lump and you have thrown that away.

Focus palettes, and why they matter most

A focus or position palette stores where a moving light points. It is the single most valuable kind, because positions are what change when you tour, when the set moves, or when the band rearranges.

Build a focus palette for every place the show actually looks: the vocal, the drum riser, the lectern, the door, the whole stage, the audience. Then a venue change is an afternoon of updating palettes rather than a week of rebuilding cues.

Colour palettes, and keeping a palette small

Store the show's actual colours, named for what they are for -- WARM, COLD, LOGO BLUE, BALLAD -- rather than every colour the fixture can make.

A colour palette with two hundred entries is a colour picker with extra steps. The discipline is the limit. Ten good colours named for their use will serve a show better than every hue in the gamut.

Intensity palettes, and when they earn their place

An intensity palette stores levels for a set of fixtures -- the wash at its working level, the specials at theirs -- so a level change that should apply everywhere is one edit.

They are the least used of the four, because levels are the thing designers change most often and most locally. Build them where a level is genuinely shared: a house curtain warmer, a standard lectern level, the level the band always plays at.

Beam palettes

Gobo, zoom, edge, iris, prism and frost -- the shape of a look rather than its colour or position. A beam palette stores a combination you keep coming back to: TIGHT, WIDE, BREAKUP, SOFT EDGE.

They matter most on shows that reuse a visual language, and they are what lets a designer say "same look, tighter" and have it happen in one touch rather than four encoder moves.

Recording a palette for the right fixtures

A palette recorded with only four fixtures selected knows about four fixtures. Apply it to eight and half of them do nothing, which is the commonest palette fault in the trade.

So record palettes with everything that will ever use them selected. It costs nothing at the time and it is tedious to fix later.

When not to use a reference

A one-off value in one cue that will never repeat does not need a palette. Storing everything is its own kind of mess, and a palette list nobody can read is no better than hard values.

The test: will this value appear more than once, or might it need changing later? Either yes makes it a palette. Both no makes it a value.

The four families, and what each protects

Reference or hard value?

How to do it

1. Select every fixture that could ever use the palette, not just the ones on stage now.
2. Build focus palettes for every place the show looks.
3. Build colour palettes for the show's actual colours, named for use.
4. Build beam palettes for the shapes the show repeats.
5. Name all of them in the show's language, in capitals.
6. Leave numbering gaps.
7. Check one palette by applying it to a fixture that was not in the room when you recorded it.

What goes wrong

Practice it

A rig with at least four moving lights, real or offline.

Tracking, and Cue-Only

A value set in cue 12 is still there in cue 40 unless something changed it. Every operator moving up meets this, and most meet it by breaking a show.

What tracking means

A cue does not store the whole stage. It stores what CHANGED. A fixture you never mentioned in cue 13 keeps whatever it had in cue 12, and keeps it until some later cue says otherwise.

So a cue list is not a series of photographs. It is a series of edits, and the picture at any moment is everything that has happened up to there.

Why anybody would want that

Because it makes a show changeable. If the front wash is at 70 through the whole first act and the director wants 60, a tracking desk lets you change it once, in the cue where it was set, and it flows forward through every cue after.

On a desk that stored complete photographs you would edit forty cues. That is the trade, and it is why almost every professional desk tracks.

The other side of that bargain

The same mechanism means an accident flows forward too. Bring a special up while you are looking at something in cue 12, record, and that special is now on for the rest of the act.

This is the single commonest way a show gets broken by somebody who knows the desk well enough to be dangerous and not well enough to be careful.

Cue-only, the escape hatch

Recording cue-only means "put this change in this cue and put it back the way it was in the next one". The change happens and does not flow forward.

Use it when you are fixing one moment rather than establishing a new state. A one-off special for one line is cue-only. A new act lighting state is not.

Reading what is tracked

Every desk colours tracked values differently from values set in this cue. That colour is the answer to "where did this come from", and it is free.

Before you change anything in an existing show, look at whether the value you are about to change was set here or tracked in from somewhere else. Changing it here may or may not be the fix.

Tracking backwards

Desks also let a change flow BACKWARDS to where the value was originally set -- usually called trace. It is how you fix "this has been slightly wrong since the top of the act" in one operation instead of hunting for the cue where it started.

Trace is the tool most worth learning after cue-only, and the one people discover years late.

Track, cue-only and trace

What the value colour is telling you

How to do it

1. Go to the cue where the problem is visible.
2. Look at the value's colour. Was it set here, or tracked in?
3. If it was set here, change it here and decide track or cue-only.
4. If it tracked in, decide whether you want it fixed from the source -- if so, use trace.
5. Ask whether it is a one-moment fix (cue-only) or a new state (track).
6. Make the change, then play forward three or four cues and watch.
7. Write down what you changed.

What goes wrong

Practice it

A cue stack of at least ten cues, real or offline.

Blocking

The specific tool for the specific failure tracking produces, and the one people reach for years too late.

What a block does

It stops a change flowing into this cue from earlier ones. A blocked value is pinned: whatever happens upstream, this cue puts it back to what it says.

It is a wall across the cue list, and like any wall it is extremely useful in the right place and a nuisance everywhere else.

Where blocks belong

At structural boundaries. The top of an act. The start of a number. Any point where the show restarts and you want it to look the same regardless of what happened before.

That is what makes a show recoverable. If cue 50 is blocked, then no matter how badly the first act went, going to cue 50 gives you cue 50.

The blackout that is not

An intensity blackout with no block is not a blackout. It is every intensity at zero and every colour, position and beam still tracking through untouched.

Which is fine until somebody adds a fixture later whose intensity you never mentioned. Then the "blackout" has a light on in it, and it will be at the worst possible moment.

Block against assert

A block stops values coming in. An assert makes this cue re-send its values even when a playback thinks they are already right. They sound similar and solve different problems.

Block is for tracking. Assert is for playback priority -- two cue lists arguing about the same fixture. If your problem involves two playbacks, assert is the word to look up.

Too many blocks

Block everything and you have thrown tracking away -- every cue is now a photograph, and the change that should take one operation takes forty.

Some programmers block every cue out of fear. It works, in the sense that the show runs, and it makes the file rigid and slow to note. Block deliberately, at structure, not defensively everywhere.

Block, cue-only and assert

Where to block on a typical show

How to do it

1. Ask what happens if the show jumps into this cue from somewhere unexpected.
2. If the answer is "it should look exactly like this", block it.
3. If the answer is "it should carry on from whatever came before", do not.
4. For blackouts, block all families, not only intensity.
5. Record which cues are blocked in the paperwork, so the next person knows the structure was deliberate.

What goes wrong

Practice it

A cue stack with at least two clear sections.

Update

A note fixed live is worth nothing until it is stored, and WHERE it gets stored decides whether you fixed one cue or forty.

Record against update

Record creates or replaces. Update puts a change back into something that already exists, and it is the one you want almost every time in a cueing session.

People reach for record because they learned it first, and re-recording a cue you meant to adjust is how references get destroyed and how blocks get added without anybody meaning to.

Updating the reference, not the cue

Here is where the palette work pays off. If the fixture's colour came from a palette and the designer wants it warmer, updating the CUE puts a hard value in that cue and breaks the link. Updating the PALETTE changes it everywhere it was used.

Most desks let you choose, and the choice is the whole skill. "Is this wrong here, or is it wrong everywhere?" is the question, and asking it out loud in a session is completely normal.

Update styles

Desks offer modifiers -- update only what you changed by hand, update everything on those fixtures, update and trace it back to the source, update and break references into hard values.

Find out what your desk's default is. The default is what you will use under pressure at eleven at night, and it should be the one that does least damage.

What update does about tracking

An update flows forward like any other change unless you tell it not to. The same track / cue-only decision applies, and it applies just as hard.

So the full question before storing a note is three-part: which target, which style, and does it flow forward. Three seconds of thought, and it is the difference between a session that progresses and one that goes backwards.

Storing while the show runs

During a show you can fix something live and update it in passing. It is normal and it is also how shows get broken at speed, because there is no time to check the three questions.

The discipline is to make the fix live, note it, and store it in the interval when you can think. Anything genuinely urgent gets stored immediately and written down so you can check it later.

Record or update?

The questions before storing

How to do it

1. Make the change live and look at it.
2. Ask where the value came from -- a palette, this cue, or earlier.
3. Decide the target: the palette if it is wrong everywhere, the cue if it is wrong here.
4. Decide track or cue-only.
5. Update, with the style you meant.
6. Play the cue back from clear and confirm.
7. Write the note down as done.

What goes wrong

Practice it

A show file with palettes and a cue stack.

Timing

The same two looks at half a second and at twenty seconds are two different pieces of theatre. Timing is the cheapest expressive tool you own and the one most often left at the console's default.

The times a cue has

An up time for things getting brighter, a down time for things getting darker, and usually a separate time for everything that is not intensity. A delay holds the start. A wait, on some desks, triggers the next cue automatically.

Most desks default to something like three or five seconds on everything, and a show left at the default feels uniform in a way audiences register as flat without knowing why.

Split times, and why they read as natural

Up faster than down is the single most useful timing habit in the trade. Things arriving quickly and leaving slowly is how light behaves in the world, and a cue built that way reads as natural rather than as a cue.

Try three up and six down as a starting point for a general change, and adjust from there. It will beat the default almost every time.

What a time is actually saying

A snap -- zero time -- is an event. The audience sees the change itself, and it lands like a cut in film. One to three seconds is a deliberate move somebody made. Ten seconds or more is invisible in the moment: the world was simply always like this.

That range is the expressive vocabulary. Choosing inside it is lighting design; leaving it at the default is not.

Discrete timing

When one thing in a cue must move at a different speed from the rest -- the colour crossfades slowly while the intensity snaps, or one special arrives late -- you give that parameter or that fixture its own time inside the cue.

This is what stops a cue being one gesture. Once a rig has moving lights in it you will use discrete timing constantly, because position moves and intensity changes almost never want the same speed.

Multipart cues

The same idea with more structure: a cue broken into parts, each with its own timing, so one recorded state can contain a sequence. Part one snaps, part two arrives over four seconds, part three follows after a two-second delay.

Use it when a moment has internal shape. Use discrete timing when one element just needs to be different. Both exist because the alternative is three cues where the designer thinks of one.

Following the music

For anything with a beat, timing is the difference between lighting that accompanies the music and lighting that fights it. Time changes to the bar rather than to a number that felt about right.

Count it. Four beats at a hundred and twenty is two seconds. A cue timed to the bar looks intentional from the house even when nobody can say why.

What a fade time says

The timing tools, and what each is for

How to do it

1. Decide what the moment is -- an event, a move, or invisible.
2. Set the up time from that decision rather than from the default.
3. Set the down time longer than the up time unless you want a snap.
4. Ask whether anything in the cue wants to be different, and give it discrete timing.
5. If the moment has internal shape, make it multipart instead.
6. For music, count the bar and time to it.
7. Watch it from the house, not from the desk.

What goes wrong

Practice it

Any two looks you can cross between, real or offline.

Mark

A moving light that arrives in position while it is already lit is a mistake the audience sees. Mark is the mechanism for never doing that.

The problem

A mover is pointing at the drum riser. The next cue wants it on the singer, lit. Play the cue and the audience watches a lit beam swing across the stage, which is either a deliberate effect or an accident, and here it is an accident.

The fix is obvious once stated: move it while it is dark. The question is how to make that happen without building extra cues by hand.

What Mark does

It tells the desk to set the fixture's position, colour and beam in an EARLIER cue, while its intensity is still at zero, so that when it comes up it is already where it needs to be.

The desk does the bookkeeping. You say "this fixture is marked" and it finds the last dark moment and puts the move there.

Auto-Mark, and when to turn it off

Most desks can do this automatically for every fixture that goes from dark to lit. Left on, it silently prevents the whole class of fault, and for most shows that is exactly what you want.

Turn it off when you WANT the move seen -- a deliberate sweep, a reveal, a fixture that is meant to be caught moving. Knowing it is a setting rather than a law is the point.

When there is no dark moment

If the fixture is lit continuously there is nowhere to hide the move, and the desk cannot invent one. Then your options are to accept the move, to dip the intensity briefly under cover of something else, or to use a different fixture.

This is a design conversation, not a programming one, and it is worth raising it as such rather than quietly producing a swing.

Marking costs time

The move has to happen somewhere, and if the previous cue is short and the move is long, the fixture may not arrive. A mark that does not complete is worse than no mark, because now it arrives visibly and late.

Check marks by running the sequence at performance speed rather than stepping through it. Stepping always gives the fixture enough time; the show may not.

Marking decisions

What a failed mark looks like

How to do it

1. Find every cue where a mover goes from dark to lit.
2. Confirm it is marked, or that Auto-Mark is on.
3. Run the sequence at performance speed, not by stepping.
4. Watch the fixture, not the stage picture.
5. Where a mark does not complete, lengthen the previous cue or move the mark earlier.
6. Where there is no dark moment, raise it with the designer.

What goes wrong

Practice it

At least one moving light and a short cue stack.

Effects

Every desk has an effects engine, they all work the same way underneath, and knowing the underneath is what lets you drive an unfamiliar one.

What an effect actually is

A generator. Instead of storing a hundred steps of a movement, you store a description of the movement and let the desk produce it continuously.

That is why an effect keeps running while everything else is static, why it can be sped up without rebuilding, and why it costs almost nothing to store.

Relative against absolute

A relative effect modifies whatever the fixture is already doing -- a circle around the current position, a wobble around the current colour. Move the base position and the effect moves with it.

An absolute effect has its own values built in and ignores the base. It goes where it says regardless.

Relative is what you want almost always, because it survives a refocus. Absolute is for when the effect IS the content -- a specific sequence of specific colours in a specific order.

The shapes

Underneath, every engine offers the same family: a sine for smooth back-and-forth, a ramp or sawtooth for a repeating sweep one way, a square or step for a chase with no in-between, and a circle or figure for movement that combines pan and tilt.

Names differ wildly. The shapes do not. Find which of these four your desk's list corresponds to and the rest of the list is decoration.

Effects on intensity, colour and beam

Movement is what people think of, and intensity effects are what they actually see most. A soft sine on intensity across a wash is the shimmer under half the concert lighting you have ever watched.

Colour effects want care, because a colour chase through unrelated hues reads as a malfunction. Build them through a deliberate small palette rather than through the whole spectrum.

Stopping an effect properly

An effect that stops leaves the fixture wherever the effect had got to, which is arbitrary. Most desks let you choose to stop on the base value instead, which is almost always what you want.

Find that setting. It is the difference between an effect ending and an effect being abandoned.

Layering, and knowing when to stop

Two effects on the same fixtures interact, sometimes beautifully and usually not. A movement effect plus an intensity effect is a standard, good combination. Three or more is generally mud.

The discipline is the same as with colour: a small number of deliberate choices beats everything the engine can do.

The four shapes, whatever your desk calls them

Relative or absolute?

How to do it

1. Select in the order you want the effect to travel.
2. Set the base look first -- position, colour, intensity.
3. Choose relative unless the effect is itself the content.
4. Pick the shape from the four, whatever your desk calls it.
5. Set size, then offset, then rate last, in that order.
6. Decide what happens when it stops, and set it to the base value.
7. Watch it from the house for at least a full cycle.

What goes wrong

Practice it

Eight fixtures, at least four of them movers.

Shaping an Effect

Rate, size and offset. Three controls that turn one effect into a hundred, and the reason two programmers get completely different results from the same engine.

Rate

How fast the cycle runs. It is the control people reach for first and the one they most often get wrong, because almost everything looks better slower than you think.

A movement that feels sluggish on a static stage is usually right once there is a performer and music. Set rate last, with the show running, rather than first in an empty room.

Size

How far the effect travels from the base value. A small size on position is a drift; a large one is a sweep. On intensity, a small size is a shimmer and a large one is a flash.

Size is where subtlety lives. Most amateur-looking effects are not the wrong shape or rate -- they are simply too big.

Offset, and the wave

Offset decides how far apart the fixtures are in the cycle. At zero they all do the same thing at the same moment, which reads as a pulse. Spread across the group, they read as a wave travelling along the rig.

This one control is the difference between eight lights flashing and a run of light moving down a truss. It is the most expressive of the three and the least used.

Direction and symmetry

Beyond a simple spread, engines offer mirrored and grouped offsets -- the wave running out from the centre, or two halves of a rig doing opposite things.

Mirrored offsets are the reliable way to make a symmetrical rig look designed rather than mechanical, and they cost one setting.

Setting them in order

Shape, then size, then offset, then rate. Shape decides what kind of movement it is. Size decides how much. Offset decides the relationship between fixtures. Rate is last because it is the only one you can judge properly with everything else settled.

Changing rate first and then size is how people spend twenty minutes on an effect that takes four.

Making an effect part of the show

An effect at one setting all night is wallpaper. The same effect with rate tied to a fader, or three stored variants on three playbacks, is an instrument.

For anything busked, put rate and size where your hands are. That is the difference between running effects and playing them.

The three controls

What offset does

How to do it

1. Choose the shape.
2. Set the size small, and increase it only until it reads.
3. Set the offset -- spread it unless you want a pulse.
4. Set the rate last, with the show running if you can.
5. Store variants rather than one setting, and put rate on a fader for anything busked.

What goes wrong

Practice it

A group of at least eight fixtures and one movement effect.

Finding a Fixture

Locating one unit in a rig of two hundred, on stage, without turning everything else off. Three tools, ten seconds, and most operators know none of them.

Highlight

Puts the selected fixture into a bright, open, obvious state -- full intensity, open white, no gobo -- temporarily, without changing anything you have stored.

It is how you find a unit during focus and how you answer "which one is channel 46" instantly. When you deselect, everything goes back to what it was.

Lowlight

The opposite half of the same idea: everything NOT selected drops to a dim level, so the selected fixtures stand out from a lit stage rather than from darkness.

Useful when you cannot black out -- during a rehearsal, or with an audience in -- and the pair together is how you work on a live stage without stopping it.

Rem Dim

Remainder dim takes everything else to zero and leaves your selection. It is the blunt version and it is the fastest way to see exactly what a group is doing.

Most desks let you set a custom level rather than zero, which is the polite version for when there are people on stage who would rather not be plunged into darkness.

Using them without breaking anything

All three are temporary display states, not stored values. That is the point, and it is worth confirming on your desk, because the fear of touching something during a show is what stops people using them.

Clear afterwards, as always. A highlight left on is a fixture at full that you have forgotten about.

The thing they replace

Without these, finding a fixture means bringing it up manually, looking, and putting it back -- which is three operations, risks leaving something changed, and is visible from the house.

With them it is one keystroke and nothing is at risk. This is a small chapter about a small feature that saves an hour a week.

The three, and when each is right

Why not just bring it up by hand

How to do it

1. Select the channel.
2. Highlight it.
3. If the stage is too bright to see it, add lowlight.
4. Confirm which physical unit it is.
5. Deselect, and confirm the stage is back as it was.
6. Clear.

What goes wrong

Practice it

Any rig of a dozen or more fixtures.

Playbacks, Submasters and Busking

What a cue list gives you against what a fader gives you, and why most live lighting outside theatre lives on the second.

Two ways to play a show

A cue list is a sequence: the show goes forward, one state at a time, in an order decided beforehand. It suits anything that happens the same way every night.

Faders are simultaneous: a set of things you can bring in and out in any combination, at any moment. That suits anything where the running order is known and the detail is not -- which is most concerts, corporate shows and events.

What lives on a fader

Looks you will want at unpredictable moments. A colour wash. The back light. An effect. A haze-and-beams state. The specials. Something for the unplanned speech from the floor.

The test for whether something belongs on a fader is simple: will you need it at a moment nobody can write down in advance?

Building a busking layout

Group your faders by what they do, not by when you built them. Intensity states together, colour together, effects together, specials together. Then your hands learn positions rather than labels.

Leave one fader for everything off, and one for a safe, neutral, always-acceptable look. Those two are what save you when something unexpected happens.

How faders combine

Two faders touching the same fixture argue, and the desk resolves it by a rule -- usually highest-takes-precedence for intensity, latest-takes-precedence for everything else.

Knowing which rule your desk uses explains almost every "why is that fixture the wrong colour" moment in a busked show. It is rarely a fault; it is two playbacks both having an opinion.

Practising it

Busking is a performance skill. It needs rehearsal in a way programming does not, and the rehearsal is: put music on, and play the rig for an hour without stopping.

You will find within ten minutes which faders you cannot reach, which looks you never use, and which one you need and have not built. That hour is worth more than another hour of building.

Bump, flash and manual override

Bump buttons fire a fader instantly for as long as you hold them, which is how hits get played. Most desks let you choose whether a bump respects the fader's level or goes to full.

Set it deliberately. A bump that jumps to full when you expected it to follow the fader is a very public surprise.

Cue list or fader?

When two playbacks argue

How to do it

1. List the moments nobody can write down in advance.
2. Build a look for each, from groups and palettes.
3. Put them on faders grouped by what they do.
4. Add a blackout fader and a safe-neutral fader.
5. Set bump behaviour deliberately.
6. Put music on and play it for an hour without stopping.
7. Rebuild what your hands could not reach.

What goes wrong

Practice it

A rig with groups and palettes built, and some music.

Building the Desk You Work From

Views, direct selects and a magic sheet are not decoration. They are the difference between finding a thing in one second and in ten, forty times an hour.

Why this is not housekeeping

A cueing session is a few hundred small operations. Shave two seconds off each and you have given the designer an extra hour of looking at the stage.

That is the entire argument, and it is why experienced programmers spend the hour before a session arranging their screens rather than building looks.

Views

A view is a saved screen layout. You want at least three: one for building looks, one for working on the cue list, and one for patch and setup.

Switching between them should be one keystroke. Rearranging windows by hand during a session is the most visible way to look slow.

Direct selects

A grid of buttons for your groups, palettes and presets, on screen, one touch each. Instead of remembering that the warm front wash is group 4 and colour palette 12, you touch two labelled buttons.

Set these up for the show you are actually on. Default direct selects are a list of everything; useful ones are the twenty things this show uses constantly.

The magic sheet

A custom picture of your rig, laid out the way the rig actually is, with each fixture or group as a touchable object. Click the upstage movers on a plan of the stage rather than finding their channel numbers.

It is the single most useful thing a desk can offer somebody working fast, and it is the feature most often never touched because building it takes an hour.

Building one worth having

Lay it out like the stage, seen from the audience. Put the groups where the fixtures are. Add the palettes you use most round the edge. Use colour to show which system is which.

Keep it readable at a glance under bad light at eleven at night, which is when you will need it. Small labels and subtle colours fail that test.

What to build before a session

Views, direct selects for this show's groups and palettes, and a magic sheet if the rig is bigger than you can hold in your head. An hour, before anybody arrives.

Nobody will ever thank you for it, and the session will run visibly better. That is most of what separates programmers who get rebooked from those who do not.

The three layers, and what each saves

A magic sheet that works at eleven at night

How to do it

1. Build or load a view for building looks.
2. Build a view for the cue list.
3. Build a view for patch.
4. Put this show's groups on direct selects, in a deliberate order.
5. Put this show's colour and focus palettes on direct selects.
6. If the rig is large, build a magic sheet laid out like the stage.
7. Sit down and pretend to work for five minutes, and fix what is awkward.

What goes wrong

Practice it

A show file with groups and palettes, real or offline.

Macros

Anything you do more than twice in a show is a macro. Macros are what make a one-person show possible.

What a macro is

A recorded sequence of keystrokes played back from one button. Whatever you can do by hand you can store and fire in one press.

That is the whole feature, and its value is entirely in noticing which repeated thing is worth storing.

What to make one for

Anything with several steps that you do under pressure. Going to a view and selecting a group. Clearing everything and releasing all playbacks. Setting up the desk for the interval. Firing three playbacks together.

The panic macro deserves special mention: one button that clears the programmer, releases every playback and brings up a safe neutral state. Every busked show should have one.

Recording one

Most desks record macros by watching you do the thing. Start learning, perform the keystrokes, stop learning. What it captures is exactly what you pressed, including the mistakes.

So rehearse the sequence once before you record it. A macro with a wrong keystroke in it is worse than no macro, because you will fire it without looking.

Naming and placing them

Name them for what they do, in the show's language: PANIC, INTERVAL, PRESET STAGE, ALL LOOKS OFF. Put them somewhere your hand can find without your eyes.

A macro you cannot find in three seconds under pressure is a macro that does not exist.

Macros that change the desk

Beyond keystrokes, macros can switch views, change settings and chain into other macros. A single button that sets the desk up for the second half -- right view, right direct selects, right playbacks loaded -- is a real thing and takes ten minutes to build.

This is where a busked show stops being a test of memory and becomes an instrument that is set up for each section.

The limit

A macro does exactly what it recorded, in a state it does not check. If the desk is not where the macro expects, it does something else, confidently, in front of an audience.

Build macros that start by clearing, so they always run from a known state. That one habit removes most macro accidents.

Macros worth having on every show

Building one safely

How to do it

1. Do the thing by hand and count the keystrokes.
2. If it is more than three, and you do it more than twice, make a macro.
3. Rehearse the exact sequence once.
4. Begin the sequence with a clear.
5. Record it, name it in capitals for what it does, and place it under your hand.
6. Test it from a deliberately wrong state.

What goes wrong

Practice it

Any console with macros, real or offline.

Patch, Beyond the Basics

Profiles, attributes, swapping a fixture type and moving show data around. The patch work an intermediate programmer actually meets, as opposed to the patch work a beginner is taught.

The profile is the translation

A fixture profile tells the console what this model's channels mean -- which is pan, which is colour, how many bits each uses, what the defaults are. It is the dictionary between your instruction and the fixture's wiring.

Almost every "the fixture does the wrong thing" fault is a profile fault: the wrong model, the wrong mode, or a library entry that does not match the firmware in the unit.

Modes, and why they bite

Most fixtures offer several modes with different channel counts. The desk must be told the same mode the fixture is set to, and nothing checks this for you.

The symptom is characteristic: the first few parameters work and everything after a certain point is wrong or shifted. Recognising that pattern saves an hour every time.

Swapping a fixture type

Half-way through a show a model becomes unavailable and the rental house sends something else. You need the cues to survive the swap.

Desks handle this with varying grace, and the thing that makes it survivable is palettes: if every position is a focus palette, a swap means re-recording palettes rather than re-recording cues. This is the moment all that discipline pays.

Moving show data around

Copying a channel's entire history to another channel, moving a block of channels, merging two show files. These are real operations that get used when a rig is rebuilt or a show is remounted.

Learn where they are before you need them, because you will need them at speed, and doing them by hand is a day.

Keywords and finding things

Larger desks let you tag fixtures with words -- ALL MOVERS, FOH, HOUSE, TOUR -- and select by tag rather than by number. On a rig of hundreds that is the difference between a selection and a search.

Worth setting up on any rig big enough that you cannot remember the numbering, which is most of them above about sixty fixtures.

Multiple-intensity fixtures

Some fixtures have more than one intensity -- a strobe with cells, a batten with segments, a fixture with separate eye and ring. The desk has to represent that, and how it does so differs.

Find out how yours does it before you patch fifty of them, because the wrong answer means re-patching and re-recording everything that used them.

What a patch fault looks like

What makes a fixture swap survivable

How to do it

1. Confirm the new model and its mode before it is rigged.
2. Patch the new profile, in the correct mode.
3. Check that every position is a focus palette rather than a hard value.
4. Re-record the focus palettes for the new fixture.
5. Re-record colour palettes, since gamuts differ.
6. Play the show through and watch specifically those fixtures.
7. Write down what changed.

What goes wrong

Practice it

A console and at least two fixture types, real or offline.

Show Files and Naming

A show file is the only thing you actually made. The commonest way to lose one is to have exactly one copy of it.

Save early, save often, save elsewhere

Consoles crash, USB sticks fail, and somebody will load the wrong file over yours. None of these is rare and all of them are survivable if there is another copy.

Save to the desk and to a stick at every natural break. At the end of each day, save a dated copy somewhere that is not the venue -- a laptop, a cloud folder, an email to yourself. Ten seconds against a day of work.

Versions, not one rolling file

Save as a NEW file at each milestone rather than overwriting: after patch, after palettes, after each act is cued, before any big change somebody asked for reluctantly.

The value is not backup. It is being able to say "that worked yesterday" and go and look, which is impossible with one rolling file.

A naming convention that survives

Date first in a form that sorts -- year, month, day -- then the show, then what changed. `2026-09-28 REBOOT after act 1 cued`.

Names like `show final`, `show FINAL 2`, `show FINAL real` are a joke because everyone has lived them. Dates that sort are the fix, and they cost nothing.

Naming inside the file

Every group, palette, preset, cue list and macro should have a name a stranger can use. This is the single clearest signal of whether a programmer is a professional.

Cue labels especially. `Act 1 Sc 3 -- lights up on the kitchen` tells the next person what the cue is for. An unlabelled cue 47 tells them nothing, and they will be operating your show without you.

What to leave behind

When you hand a show over: the current file, a note of what changed today, the known quirks, and anything that exists only in your head.

Being the only person who can run your file feels like security. It is a ceiling, and it is why people stay on the same show for years.

Archiving a closed show

The final file, the paperwork as-built, and a note of what you would do differently. Shows come back, venues repeat, and a remount from a good archive is an afternoon rather than a rebuild.

The last item is for you rather than for them, and it is the one that makes you better.

When to save a new version

Naming, inside and out

How to do it

1. Save to the desk.
2. Save a dated copy to a stick.
3. Save a dated copy somewhere off site.
4. Label anything you built today that is still unnamed.
5. Write down what changed and what is outstanding.
6. Leave the note where whoever has it tomorrow will find it.

What goes wrong

Practice it

Any show file you have worked on.

Pre-Programming and Working Blind

The hours that decide whether a cueing session is creative or administrative, and the skill of editing a cue that is not on stage.

What pre-programming is for

Everything that does not need the designer present. Patch, groups, palettes, a first pass at positions, views, direct selects, the magic sheet, macros.

Do all of it before the session and the designer's time is spent on looks. Do none of it and the first two hours of a paid session are spent watching somebody build groups.

Offline software and visualisers

Both major manufacturers give away software that runs the real console on a laptop. A visualiser adds a 3D model of the rig so you can see roughly what a look does without a stage.

A visualiser is not a stage and its colours lie. What it is good for is structure -- checking that positions are roughly right, that effects run the right way, that nothing is obviously missing. That is most of pre-programming.

What not to pre-programme

Anything that depends on seeing the real thing: exact levels, precise focus, colour against a real set, anything involving a face.

Bringing over-committed pre-programming to a session wastes time, because it all gets rebuilt anyway and the designer has to watch. Build structure, not looks.

Working blind

Editing a cue that is not currently on stage, without the stage changing. It is how you fix cue 40 while cue 12 is showing, which during a rehearsal is the only way to work at all.

Every desk has it. The danger is forgetting you are in it -- making changes, wondering why the stage is not responding, and then discovering you have edited the wrong cue.

The discipline for blind work

Say out loud, or write down, which cue you are in. Come out of blind as soon as you are done. Check the change by playing the cue when you next get a chance rather than assuming.

Most blind accidents are not wrong values; they are right values in the wrong cue.

Using rehearsal time

A rehearsal is hours of the show running with nobody asking you for anything. That is when the notes from the last session get done, blind, while the stage carries on.

Programmers who use rehearsal this way arrive at the next session with the list clear. Programmers who watch arrive with it intact.

Before the session, and during it

What a visualiser is and is not good for

How to do it

1. Note which cue you are going into.
2. Enter blind.
3. Make the change.
4. Say or write what you changed and in which cue.
5. Leave blind immediately.
6. Play that cue back at the next opportunity and confirm.

What goes wrong

Practice it

A cue stack and offline software or a real desk.

Working With a Designer

A cueing session is two people and one pair of hands. Your job is to make the designer faster, not to have opinions.

What the designer needs from you

Speed, and not having to explain twice. They are holding a picture in their head and every second it takes to appear is a second it can slip away.

The best compliment in this job is that a designer forgets the console is there.

Keeping ahead

Anticipate. If they have built three looks that all start from the back light, have the back light ready. If they are working through a song, have the next section's groups selected.

Being one step ahead is what separates a programmer from a typist, and it comes from listening to what the show is doing rather than waiting for instructions.

When you disagree

You will see things they miss -- a fixture that will not reach, a colour that will not survive the camera, a cue that will not have time to mark.

Say it once, briefly, as information rather than as an opinion: "that mover won't make it in two seconds". Then do what they decide. Saying it twice is the thing that gets programmers replaced.

Notes, and holding the list

In a session, notes arrive faster than they can be stored. Keep a written list, mark what is done, and report the state when asked.

"Seventeen notes, fourteen done, these three need a decision" is the sentence that makes you trusted with somebody's show.

Absorbing changes

Changes are the normal condition of tech, not a sign anything has gone wrong. What causes damage is a change nobody recorded.

Every change gets stored, or written down as not-yet-stored. There is no third category, and the third category is where shows get broken.

The pace of a session

Sessions have a rhythm: long stretches of small adjustments, then a burst where everything changes. Match it. Do not offer improvements during the fast part, and do not go silent during the slow part.

And know when to call a break. A session that has stopped making progress is a session where somebody is tired, and twenty minutes recovers more than pushing through an hour.

What makes a session fast

Saying a problem well

How to do it

1. Build everything structural beforehand.
2. Start a written note list before the first look.
3. Listen to where the show is going and preselect for it.
4. Say a real problem once, briefly, as information.
5. Store each note as it is agreed, or write it as not-yet-stored.
6. Report the state of the list when asked.
7. Call a break when progress stops.

What goes wrong

Practice it

Any cueing session, or a rehearsal of one with a colleague.

The Fixtures You Programme

Conventionals, movers, LED and media are four different things to programme. Treating them the same is why some rigs feel harder than they should.

Conventionals

One parameter. Intensity. Everything else about them -- colour, angle, shape -- was decided when somebody hung and gelled them, and cannot be changed from the desk.

Which makes them simple to programme and inflexible to fix. If a conventional is the wrong colour, that is a focus-session problem, and no amount of programming will help.

Moving lights

Many parameters, mechanical, and slow relative to a cue. They need marking, they need time, and they need focus palettes for every position.

They also fail differently -- a mover that has lost its calibration points somewhere near where it should, which is much harder to spot than a light that is simply off.

LED fixtures

Colour is a parameter rather than a physical gel, which is the freedom people notice, and colour MIXING differs by fixture, which is the trap they do not.

Two LED fixtures from different makers given the same numbers will not match. That is why colour palettes are recorded per fixture type, and why a palette recorded on one model and applied to another needs checking with your eyes.

Dimming curves and the bottom of the fade

Different fixtures behave differently at the bottom of a fade. Some LED units step visibly below about ten per cent; some snap off at two; tungsten glows down smoothly and keeps glowing after zero.

Mixing them in one wash and fading to black is where this shows. Check the bottom of every fade, because the top always looks fine.

Media servers and pixel-mapped rigs

A media server is a fixture with content in it, and a pixel-mapped rig is a set of fixtures being driven as one picture. Both are programmed through a small number of parameters that select and position content rather than by setting each fixture.

An intermediate needs to know what they are, how to bring them up and take them out, and who to ask. Programming them properly is a book of its own: Media Servers 101.

Programming a mixed rig

Real rigs are all four at once. The practical consequences: record palettes per fixture type, check colour matches by eye, check the bottom of fades, and give the movers time the conventionals do not need.

None of that is difficult. All of it is invisible until a show looks slightly wrong and nobody can say why.

Kinds of fixture, and the habits each needs

What to check on a mixed rig

How to do it

1. Bring each fixture type up on its own and look at it.
2. Put the LED types side by side at the same numbers and compare by eye.
3. Record colour palettes per type, correcting by eye rather than by number.
4. Fade the whole rig slowly to black and watch the bottom of the fade.
5. Time one mover move against a conventional crossfade and note the difference.

What goes wrong

Practice it

A rig with at least two fixture types, ideally including LED.

When the Rig Is Not What You Programmed For

A different venue, a missing fixture, half the rig on a different bar. The intermediate skill is adapting a file rather than rebuilding it.

Why this is the normal case

Shows tour. Venues differ. Rental houses substitute. Something breaks on the morning. A show file that only works in one room is a show file that works once.

Everything in this book about references exists for this chapter. This is where palettes stop being tidiness and start being the reason you go home on time.

The order to adapt in

Patch first -- get the desk agreeing with what is actually hanging. Then focus palettes, because positions are what change. Then colour palettes if the fixture types changed. Then, and only then, look at cues.

Work in that order and most shows need no cue edits at all. Work backwards from the cues and you will rebuild the show.

Fewer fixtures than the file expects

Decide what each missing fixture was FOR, then find who else can do that job. A missing back light might be covered by two neighbours re-aimed; a missing special usually cannot be covered at all and needs a conversation.

Write down every substitution. A show running on undocumented substitutions is a show nobody else can take over.

More fixtures than the file expects

Easier, and it has its own trap: adding fixtures to groups without adding them to palettes. The new units join the wash and then do nothing when a colour palette is called.

Add to the groups, then re-record every palette with the new fixtures selected. Then check by calling each palette and looking.

A completely different rig

Sometimes the honest answer is that the file is not adaptable and the fastest route is to rebuild from the paperwork, keeping the cue structure and timings.

Knowing when to stop adapting is a real judgement. The signal is usually that you have spent longer diagnosing than a rebuild would take.

Keeping a file portable

Every position a focus palette. Every colour a colour palette. Groups by function rather than by channel number. Cues built from references only. Nothing that depends on a specific channel number existing.

Build that way from the start and a venue change is an afternoon. Build any other way and it is a week, every time.

Adapting, stage by stage

What makes a file portable

How to do it

1. Get the new plot and compare it with the file's patch.
2. Patch the differences.
3. Walk every focus palette and re-record it for this room.
4. If fixture types changed, re-record colour and beam palettes by eye.
5. Play the show through, watching for anything that did not follow.
6. Fix what is left in the cues, and write down every change.
7. Save as a new dated version for this venue.

What goes wrong

Practice it

A show file and a rig that differs from the one it was built for.

Safety, and Where This Leads

You move fixtures over people's heads from a desk you cannot always see the stage from. And programming is a rung, not a summit.

The specific hazard of a console

Every other lighting job puts you in the room with the consequence. Programming does not. You can move a heavy fixture at speed, from behind a desk, while somebody is on a ladder underneath it, and never know.

That is not a theoretical risk. It is the reason the discipline below exists, and it costs about four seconds.

Announcing before it moves

Before you move anything mechanical during a work call, say so. "Moving the upstage movers" is the whole procedure. If you cannot see the stage, ask somebody who can.

During a focus call, nothing moves without the person on the ladder knowing. During a show, this is why marks exist -- so movement happens at planned moments rather than at surprising ones.

Homing, and the rig that jumps

Powering up or re-homing a rig makes every fixture move at once, fast, with real force. It is the single most dangerous thing a desk can command.

Never home a rig without announcing it and looking. Somebody working on a fixture when it homes will be hurt, and the desk gives no warning at all.

Strobes and photosensitivity

Strobe effects can trigger seizures. There are published guidelines and many venues and broadcasters have their own limits, and they are not advisory.

Find out what applies where you are working before you programme anything flashing. And warn the room before you test it, because somebody in that room may be affected and will not want to announce it.

Where programming leads

For some people it is the destination -- a specialist career, in demand, well paid, on the biggest shows. For others it is the bridge into design, because you have spent a thousand hours watching designers decide.

Both are real. Knowing which you want changes what you practise: programmers practise speed and systems, designers practise looking and describing.

What gets you the next call

Being fast, being calm, having the file ready, saying a problem once, and leaving a file somebody else can use. None of that is about knowing more syntax than the next person.

The programmers who work constantly are not usually the ones who know the most obscure features. They are the ones a designer stops noticing, because everything just appears.

The safety rules at a console

Where this leads

How to do it

1. Before moving anything mechanical, announce it.
2. If you cannot see the stage, get eyes on it before you move anything.
3. Never home a rig without announcing and looking.
4. Check local strobe limits before programming anything flashing.
5. Warn the room before testing a strobe.
6. During shows, keep movement to planned moments using marks.

What goes wrong

Practice it

Your own working practice, and an honest look at it.

Glossary

Beyond Operation

Operating runs a show; intermediate craft creates a richer one.

From running to creating

If you have come from Lighting Operation, you can already patch, build looks, record cues, and run a show. Lighting Intermediate is about creating richer, more dynamic, more intentional lighting: using advanced programming tools to work efficiently, controlling moving lights fluently, building cues with movement and effects, and designing looks that genuinely serve the show. The difference between a basic lighting show and a compelling one is largely this deeper craft, and developing it is what turns an operator into a lighting creator. The console skills are the same foundation; intermediate adds the depth that makes lighting expressive.

The shift is from making the lights do what you programmed to making them do something compelling. You already can run a cue stack; now you learn to program more powerful looks faster, to make moving lights dance with intention, to add dynamic effects, and to think about what the lighting should achieve for the show. This is where lighting becomes a creative craft on top of the technical operation.

Programming smarter, not harder

A core intermediate theme is programming efficiently using the console's powerful tools rather than setting every fixture individually. Modern consoles offer groups (controlling many fixtures together), palettes (saved colours, positions, and beam settings you can reuse), and an effects engine (automating movement and chases) — tools that let you build complex looks far faster and more consistently than fixture-by-fixture. Learning to use these tools is what makes intermediate programming both more powerful and more efficient. The intermediate programmer works smart, leveraging the console's capabilities.

This efficiency matters because intermediate and advanced shows have many fixtures and many looks, which would be impossibly slow to program one fixture at a time. Groups, palettes, and effects are how a programmer builds a rich show in reasonable time, and how they keep it consistent and easy to adjust. Mastering these tools — the subject of the next chapter — is the practical core of stepping up from basic operation to intermediate programming. Smart use of the console's power is the intermediate craft.

Advanced Programming Tools

Groups, palettes, and effects: the power tools of efficient lighting programming.

Groups and palettes

Two foundational intermediate tools are groups and palettes. A group is a saved selection of fixtures you control together — all the front wash, all the moving heads, the back light — so you can select and adjust many fixtures at once instead of one by one. A palette is a saved setting you can reuse: a colour palette stores a specific colour, a position palette stores where moving lights point, a beam palette stores a beam look. Once built, you apply palettes to fixtures or groups instantly, and reuse them across the show. Groups and palettes make programming dramatically faster and keep a show consistent (the same blue, the same position, used everywhere).

These tools also make a show easy to adjust: change a position palette, and every cue using it updates; this referencing is powerful for keeping a large show manageable. The intermediate programmer builds a foundation of groups and palettes first, then programs cues using them, which is far more efficient than raw fixture-by-fixture work. Mastering groups and palettes is the first big step in intermediate programming, turning slow manual work into fast, consistent, adjustable programming.

The effects engine

The effects engine is the console tool that automates movement and dynamic looks — making lights move in patterns (circles, sweeps, fans), colours chase across fixtures, intensities pulse, all generated automatically rather than programmed frame by frame. This is how the dynamic, moving lighting of concerts and events is created efficiently: instead of manually programming every step of a moving-light sweep, you apply an effect that generates the movement, then shape its speed, size, and how it spreads across fixtures. The effects engine is what gives intermediate lighting its energy and motion.

Using effects well is a craft: choosing effects that suit the music and moment, controlling their speed and intensity, and combining them with the static looks for a rich result. Overused or wrong, effects look chaotic; used with skill, they make lighting come alive with the show. The intermediate programmer uses the effects engine to add dynamics — movement, chases, pulses — that a static cue stack alone cannot achieve, and combined with groups and palettes, builds dynamic shows efficiently. These three tools — groups, palettes, effects — are the core of intermediate programming.

Moving Lights & Richer Cues

Make moving lights dance with intention, and build cues with depth and motion.

Working fluently with moving lights

Moving-head fixtures (from Lighting Basics) are central to modern lighting, and intermediate skill is controlling them fluently — their position (pan and tilt, where they point), colour, and beam, all of which can change and move. Working with moving lights means programming where they aim (using position palettes), how they look (colour and beam), and how they move (manually or with effects). Fluent moving-light control is what creates the dynamic, dramatic looks of concerts and events — beams sweeping, fixtures recolouring and repositioning between looks. It takes practice to control moving lights smoothly and intentionally rather than chaotically.

Position palettes are especially valuable for moving lights: storing the key positions (the stage, the drummer, the audience) so you can send fixtures to them instantly and consistently. Combined with colour and beam control and the effects engine for movement, fluent moving-light programming lets you create the rich, dynamic looks that define exciting lighting. Mastering moving lights — pointing, colouring, shaping, and moving them with intention — is a defining intermediate lighting skill.

Building richer cues and looks

With these tools, intermediate cues become richer than the basic looks of Lighting Operation: combining many fixtures via groups, applying consistent colours and positions via palettes, adding movement and dynamics via effects, and layering these into looks with depth and energy. A rich cue might have a coloured wash, moving beams sweeping, and a highlight on a performer, all coordinated — far beyond a simple static look. Building these richer cues, and sequencing them into a dynamic show, is the intermediate programming craft in action. The cues do more, and the show comes alive.

This richness serves the show: a dynamic concert look, an elegant corporate scene, a dramatic theatrical moment, each built from the tools into a cue that achieves the intended effect. The intermediate programmer thinks about what each look should accomplish and builds it using groups, palettes, effects, and moving lights to get there. Richer, more intentional cues, sequenced into a compelling show, are what intermediate lighting delivers beyond basic operation — and they lead naturally into thinking like a designer.

Beginning to Design

Tools create looks; design decides what looks the show actually needs.

Lighting design thinking

Beyond programming the tools, intermediate lighting begins design thinking — deciding what the lighting should achieve for the show, not just how to make a look. Design considers the functions of light (from Lighting Basics): visibility and focus (lighting the right things, drawing the eye), mood and colour (creating the right feeling), and dynamics (changing with the show's energy and moments). The intermediate lighting person starts asking what does this show need from the lighting — what should the audience see and feel — and then uses their programming craft to deliver it. Design is the why behind the looks; programming is the how.

This is the beginning of the journey from programmer towards designer (a path that continues in the book Lighting Design). At the intermediate level, you start making intentional design choices — this segment should feel warm and intimate, this one energetic and bold, the focus should be here — and building looks that serve those intentions. Even as an operator or programmer, thinking about what the lighting is for makes your work far more effective. Design thinking elevates programming from making looks to making the right looks.

Looks that serve the show

Good lighting serves the show — the music, the speaker, the moment, the mood — rather than just being technically impressive. An intermediate lighting person learns to read what a show needs and create lighting that supports it: enhancing the energy of a song, focusing attention on a presenter, setting an emotional tone, marking transitions. The lighting becomes part of the storytelling and the experience, not a separate light show. This service mindset — lighting in support of the show — is what distinguishes thoughtful lighting from mere button-pushing, and it begins at the intermediate level.

Practically, this means coordinating lighting with the rest of the show (the music, the performance, the other departments), choosing looks appropriate to each moment, and using your dynamic programming to follow and enhance the show's flow. Whether running cues to a precise show or busking live to music, the goal is lighting that serves and elevates what is happening. Combining design thinking (what the show needs) with intermediate programming craft (how to deliver it) is what makes lighting genuinely good — the destination this book builds towards.

Putting Intermediate Lighting Together

Combine smart programming and design sense into compelling, efficient lighting.

The complete intermediate craft

Pulling it together, intermediate lighting combines efficient programming (groups, palettes, effects), fluent moving-light control, richer dynamic cues, and beginning design thinking into the ability to create compelling lighting efficiently. The intermediate lighting professional builds shows that are richer and more intentional than basic operation, using the console's power to work smart and design sense to make the looks serve the show. This is a substantial step up — from running lights to creating lighting that genuinely enhances a show, built efficiently enough to handle real, complex productions.

All of it rests on the foundations: the four properties of light, DMX and patching, building looks and cues, and running a show. Intermediate adds the programming depth, the moving-light fluency, and the design awareness on top. The combination — solid foundations plus efficient advanced programming and emerging design sense — is what lets you create the dynamic, intentional lighting that modern shows need.

Developing your eye and growing

Like audio's ear, lighting has its eye — the developed sense for what looks good and what serves the show, which guides every design and programming choice. You develop it by lighting constantly, watching how lighting is used in shows and productions you admire, and learning to see what makes lighting effective (the focus, the colour, the movement, the mood). Tools and technique matter, but lighting is ultimately judged by how it looks and what it achieves, so a great lighting person is above all someone with a great eye and intention. Deliberately developing your eye turns the techniques here into real artistry.

From here, growing in lighting means continuing to develop your eye and craft, mastering specific consoles deeply, and moving towards advanced and specialist roles — lighting design, lighting direction, and the like (covered in Lighting Design and Lighting Direction & Leadership, other books in this series). The intermediate skills here — efficient programming, moving lights, richer cues, design thinking — are the platform those specialties build on. Keep programming, keep watching great lighting, keep refining your eye, and you will continue from solid intermediate lighting toward true mastery and design.

Try this. Watch a concert or event video and study the lighting: what's it doing for each moment — focus, mood, energy? Then imagine how you'd build one of those looks with groups, palettes, and effects.

Competencies this course closes

Lighting Intermediate builds on the LIGHT_FUND/LIGHT_PROG clusters in the Reboot Gap Library, deepening programming and design towards advanced lighting roles.

Assessment

Hands-on & sign-off

Intermediate lighting is built on a real console. The learner uses groups, palettes, and effects, controls moving lights fluently, builds richer dynamic cues, and makes design-minded look choices. A mentor signs off when the learner creates compelling lighting efficiently.

Lighting Intermediate · Reboot AV

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