Automated lighting programming encompasses a vast amount of processes and routines, but actually the entire practice can be broken down into four segments. Each of these segments is very complex on its own, and all four are required for any lighting programming project. Programmers do not have to master each of these areas, but they certainly need to have a good understanding and be proficient in each. All automated lighting programming projects require work in the following areas: Patching, Preparation, Parameters, and Playback.
The First P: Patching
Before any show can be programmed, the patch must be entered into the console. Usually this starts by adding in the quantities of fixtures that will be controlled by the desk. This is done by selecting a fixture type and mode from a list of manufacturers. Next, each fixture must be numbered according to how the programmer or LD will select the fixtures. Then the fixture numbers must be matched up with the DMX start addresses that will be set at the actual fixtures. Sometimes this data is originally created in the process of adding the fixtures to the desk, while other times the patch is provided for the programmer to manually enter.
The most important point of the patch process is for the console to understand what fixtures it will be talking to and the associated communication path. Usually this means that the programmer assigns a DMX universe and start address, but in more complex situations it requires selecting network protocols, output devices and more. Also, within the process of patching, the programmer often has the ability to alter other operational parameters such as pan/tilt orientation, default values, dimming curves and other items. The patch process can be as simple as adding fixtures and assigning DMX addresses or extremely complex. In either case, it is essential that a programmer understands the basic principles and processes of patching.
The Next P: Preparation
Once the patch is confirmed to be correct, the next step is to prepare for the programming session. The order in which things are prepared is irrelevant, but each of the following are very important to a successful programming session. First, the windows on the screens need to be configured. With most consoles, you can move and resize windows as desired and save these configurations as “views.” Multiple views are often created to allow easy shifting between programming duties.
The creation of fixture groups is an essential tool for quick selections of fixtures. Some groups can be auto-created in the patch process, but other groups relative to the specific show will need to be manually made. Once the groups are made, the next step is to build a number of palettes/presets. These are references to specific parameter values that can be stored and recalled at any time. For instance, a programmer will store a position for all fixtures in the Down Center stage position. Then, at any time when programming, this position can be quickly recalled at the press of a button. The programmer does not have to manually move the fixtures every time they need to point to the Down Center position. Furthermore, these references are stored within the playback items instead of actual parameter values. Now the reference can be updated, and all playbacks will auto-update as well.
Once views, groups and palettes/presets are built and stored, the actual lighting programming can begin. This takes us to the third P.
The Third P: Parameters
Every person who has ever wanted to program moving lights is really looking for this fun part of the process. This is the time when fixtures are selected and parameters are adjusted to create looks on stage. Once the looks are made, they must be recorded into some sort of playback within the console. There are literally thousands of different tools within consoles to aid programmers in adjusting and modifying parameters. Some of these include effects, fanning, encoders, if/then statements, palette/presets, selection tools, graphical feedback, chases and much, much more. However, parameter adjustment does not just relate to parameters of fixtures, but also to parameters within the console and the show file. Timing, macros, timecode and external triggers are just a few of the additional parameters that lighting programmers work with on a daily basis.
A good programmer will learn as much as possible about the tools included in their console. Then they must decide in the moment the best tool to use for the desired look. Too often, though, programmers get bogged down on the console functions and forget about the end result on stage. The show and the audience never see how something was created in a desk, so it is important to always keep a focus on the end goal.
The Last P: Playback
All of a programmer’s hard work is not worthwhile without playback of the data. Sometimes the programmer will be the operator, and other times the show will be automated, or have a lighting director or designer in control. In any of these scenarios, the lighting programmer must understand what is going to happen when playback of their work occurs. A good understanding of basic concepts such as tracking, LTP, HTP, marking, timing and priorities is essential. As a show is programmed, the programmer must always be thinking about how it is going to look as cues are played and how they will interact with each other and other show elements.
Every playback built should be tested by the programmer. If an LD asks for cue 4 to be a fly-in of the spot fixtures in blue, then this is what should happen when the cuelist advances from cue 3 to cue 4. However, if the programmer makes a tracking mistake, then this may not be the case. The fixtures might fly-in, but be in a red color. A quick test of the playback before the production or rehearsal is essential to ensure that the programming is properly created.
A Bonus P: Protect
All four of the above “P” words are crucial elements of any automated lighting programming project. Every show file requires Patching, Preparation, Parameters and Playback. However, there is one other “P” word that is equally important: Protect. It is not only the programmer’s job to enter the data into the desk, but also to save and protect this data so that it is never lost. A good saving routine (both on the console and to external media) is imperative. No one should ever lose more than 30 minutes of work due to a console crash or other unforeseen event. A proper data saving process is the most essential insurance for any lighting programmer.
On your next production, notice how your routines can be broken down into these four segments, and ensure that you are maximizing your use of each. As you work within each area, look for new tools or processes that you have never used. Take the time to learn more and improve your programming skills. And, always, be sure to save often.
