Console Programming

Using Programmer Based Lighting Controllers

An article looking at the concepts and use of programmer based moving light consoles. The backbone of professional lighting consoles, using a “Programmer” is a jump from recording with a conventional “record output” lighting desk.

Traditional output based programming

Your first introduction to programming a lighting control often involves storing dimmer levels on a conventional light board. Set levels, see the changes on stage, hit Record. Make more changes, hit Record. Whatever you see on stage is stored in a scene memory, to be played back on cue. This is often referred to as “output based programming” for obvious reasons and is simple enough to understand.

// Bit to get out of the way – Some conventional consoles, particularly theatre orientated desks, use a concept called “Tracking” which complicates things a bit. If you know what tracking is, great. If not, it doesn’t matter – we’ll look at that some other time. This article is all about using a Programmer.

Programmer based recording is an efficient and powerful feature of most professional level automated lighting consoles – Whole Hog, Grand MA, Avolites, Cham Sys…. It also requires a different mindset of the operator which can seem alien to a beginner, used to a “record what you see” workflow. The programmer feature is extremely good for handling intelligent fixtures, but it is worth noting that entry level moving light controllers often only record output in the conventional way. On Stage Lighting recommends you try the MagicQ PC software precisely because it is a freely available system that uses professional lighting programming concepts and syntax that prepares a beginner for other world class lighting consoles such as the Hog, MA etc.

The Programmer

OK, so you might worked out that we are not talking about the palid weirdo with a Sharpie who haunts the FOH position. The Programmer is dedicated area of memory on the lighting console that the operator uses to create cues with.

The Concept

The operator starts with an empty paper bag – the programmer. They choose different parameters such as Colour, Gobo, Pan, Tilt for particular fixtures. Like shovelling different Pick ‘n’ Mix into the empty bag. “One of those, a couple of those – Oh no, perhaps I’ll put that one back…” When the operator is satisfied with their Pick ‘n’ Mix, they dump the whole lot into their shopping bag – a scene memory, chase or palette.

When they have finished, the operator shakes the bag upside down to make sure it’s empty. AKA Clearing the Programmer. The clear button is the one that wears out the second fastest on an automated lighting console, after the Go button.

OK, so maybe you’re confused and now I can’t stop thinking about sweets. The Programmer is a holding area for things that we wish to record, regardless of the overall output of the console.

But why on earth would I want to record stuff that isn’t exactly what I see on stage?

The advantages of programmer vs. output based recording include:

  • You can choose which attributes/parameters to save. An output based system just dumps all outgoing values into a memory.
  • Only certain fixtures can be recorded into a cue. This cue can be mixed with other cues “on the fly”. See Concert Programming in 30 Mins and Using Submasters for Busking Bands for some examples.
  • It doesn’t matter what the console is outputting – multiple scenes, chases. You can make quick edits and additions to cues, even ones that are not currently on stage. This makes sneaky editing during rehearsals (and even the show!) possible without ruining your programming.
  • Only recording the essential parts of a scene (ie. the fixtures that you actually need) conserves console memory.
  • Er, it’s just more flexible – OK?

The programmer view of the ChamSys MagicQ.
The red fields Intensity, Pan and Tilt are active in the programmer. All the other attributes are not.

Using Programmer Based Recording

We’ve looked at the concept, but what about a practical example? Every console programming operation starts with a blank slate. Clearing the programmer so that there are no fixtures, values or even crumbs in there.

Selecting two of our moving spots, we wind up their intensity. That gives us a Dimmer level in the programmer but nothing else. If we recorded that scene now it would just fade up the fixtures, regardless of their colour, gobo or position. Those parameters would remain from the previous cues. (a guide to Latest Takes Precedence / LTP attributes, if you are unfamiliar with them)

We move on. Keeping the fixtures selected, we make some position adjustments – Pan and Tilt. Doing this places those to parameters into the programmer along with intensity levels. If recorded now, the cue would also include a move to this new position.

Making adjustments to new attributes, gobos, colours etc. puts more values into the programmer. When you have finished, recording the new cue will incorporate these values. Finally, clearing the programmer will wipe the slate clean for the next time.

Can I just record all attributes of a fixtures, even if I didn’t change them?

Yes, any fixture that is active in the programmer (one that has been selected AND had some attributes changed) can have all of it’s attributes recorded in a scene. Different consoles call this different things – whole fixtures, record by fixture, whole memories. Recording a whole fixture cue will guarantee that all your chosen fixtures will do what you want, regardless of other cues still running.

The downside to recording cues using a Programmer is that it can be hard predict outputs to stage for the less experienced. There are a few things you can do about this:
Always record whole fixtures/memories. What You Saw Is What You Get next time.
Record your show cues in order of playback and never hit clear – ever. Or use a tracking console.

But these kind of defeat the object of using a Programmer in the first place.

Advanced programming options.

So, we’ve found out that using a programmer based console give us the option to choose exactly what information goes into our cues and which attributes are changed. There are other powerful programming features associated with the concept, ideal for mustering the large amounts of information in automated lighting control. These features include:

Saving only certain attributes to a scene memory, regardless of the information in the Programmer. This is like picking certain sweets back out of your Pick ‘n’ Mix bag again.

Using the Programmer to remove unwanted parameters from an already saved cue. This is seriously handy and is often called Record Remove.

Picking certain fixtures and attributes from existing cues, putting them into the Programmer and adding other data before saving it all as a new memory.

Still confused?

Reading about a subject is never substitute for fiddling with buttons and trying stuff out. If you are keen on learning the programming of moving lights, understanding the Programmer concept is a vital step. All professional operators, whatever console they use, would agree that you just can’t handle large amounts of moving light data without it.

Hopefully, you have a better understanding of programmer based lighting control and if you have any specific questions, put them in the box below as usual.

Note to Zero88 users:
Many OSL readers have access to small moving light desks such as the Zero88 Frog range and the Jester ML. Zero88 have a system referred to as “tagging”. Attributes that are adjusted are “tagged” (similar to the programmer concept) and either whole fixtures (whole memories) or only changed values (partial memories) can be recorded. Although not exactly the same as the Programmer concept in this article, they two share many of the same characteristics. It you already familiar with “tagging”, you should find it easy to move onto programmer based consoles, which include the new Zero88 generation Leap Frog and Frog II.

  1. Craig Finch

    Once you start using moving lights, there’s no way around learning to program. Unfortunately, some of the older consoles set standards that are no longer optimal. For example, the Hog console tried to conserve memory by only storing the changes from one cue to the next. This causes endless confusion for the beginner, and with the dramatic advancement in processor power, is no longer necessary. New consoles like the MagicQ disable this behavior by default.

    I like to think about programming in terms of “layers” of light. I might have one list of cues for colored stage washes, another list for colors on the set and backdrop, and another for “special effects” lights. That makes it easy to make different stage looks by “layering” the different elements. I usually put white “special” lights on their own faders, so I can light each performer “on the fly” as needed. Depending on the console, moving lights can be added in with the fixed lights, or they may have to be placed on their own cue lists. With the Hog, I prefer to separate them, but newer consoles are better at mixing fixture types on the same list.

    Hopefully, as new console come to market and computers improve, some newer, more logical programming paradigms will come along.

Leave a Reply

Your email address will not be published.