Whether programming a concert, corporate event, television show or any other production, there are always opportunities to expand the playback capacities through advanced programming. The automated lighting programmer must be able to understand the needs of the production as well as the capabilities of the console in order to create the required interconnectivity of lighting playbacks.
» Simple to Advanced
At their simplest level, live productions can be programmed with one single cuelist (or sequence). This is a stack of cues that is played back in order, one cue (or step) at a time. This playback methodology is a starting point for almost all types of productions, as it provides an organized format of pre-programmed cues.
Sometimes, however, you may need to create a chase (or loop) that is triggered via the main cuelist. For instance, I programmed a concert where, at every chorus of a particular song, I needed to play the same four looping cues. The timing between these four cues was very specific, so I built them as a separate chase playback.
Then, in the master cuelist, I had the “chorus” cues trigger the chase playback. The chase would then loop through the chorus portion of the music, and the next cue in the main cuelist would deactivate the chase.
Building these triggers required an understanding how my console allows for triggering and releasing of playbacks from the main cuelist.
But there was also more interconnectivity that needed to be applied. Although I could easily trigger and release the chorus chase as needed, I also had to think beyond that, about the entire production.
When the chorus chase was triggered, it needed to always start on its first step. Because it was played four times during the song, this meant that I had to ensure that it reset to its first cue after it was released.
This was an option in the chase playback that I had to enable. Had I not done so, then each time it was triggered, it would just start from where it left off.
In addition, I had to plan for stopping and restarting during rehearsals. If the band stopped and wanted to restart the song, I did not want the operator to have to figure out what playbacks were in use for the song. So I put a release command for the chase playback on the first cue of the main cuelist. This way, the operator could know that when Cue 1 is played that the correct state of the song is live on stage.
» A Matter of Priority
Most automated lighting consoles provide programmers with the ability to assign a priority level to individual playbacks. Just as the name implies, a playback can be given a numeric value that gives it more control than those with a lower numeric value. This can be very useful when considering the interactive capabilities of a production’s lighting. There are many uses for this feature, and it is important that you understand the basic principles behind the idea.
A common scenario is to set a high priority for a playback that assigns a group of fixtures to light a podium. When these lights are focused and illuminated on the podium, you generally do not want any other playbacks to override the podium lighting (because usually the person at the podium is the most important). If you suddenly need to trigger an audience ballyhoo, you want to ensure the podium lights stay put. By assigning the podium playback a higher priority than other playbacks, the console will ensure that their programing is never overridden by other playbacks with lower priority. So even if your ballyhoo playback includes the same fixtures that are in the podium playback, the fixtures in the podium playback will always overrule the ballyhoo playback.
As with every console feature, the names and exact procedures can vary. In fact, some consoles put a greater importance on higher-numbered priorities, while others place it on lower numbered priorities. Always be sure to read your console’s user manual to fully understand the terminology and capabilities of your desk.
» A Complex Example
I have been lucky to have been involved in some very intricate lighting programming that required lots of thought and interconnectivity above just the programming of the lights. All genres of production have opportunities for these types of systems, but I most commonly find them on permanent installations.
With these systems, there is typically some sort of input screen (it may or may not be part of the console) where a user will expect the buttons to operate in a particular manner. They will also assume each of the buttons work independently of each other as the user will have a very limited knowledge how the lighting programming is organized and constructed.
Recently, I was working on one of these systems for a museum. The task seemed simple at a glance: have a background cuelist that is always playing, then have buttons that the visitors can trigger to see specific items in the museum, which then restore to the main background cuelist after a specific time.
Additional buttons on a maintenance screen allowed for custom overrides for museum events, maintenance and more. I had to plan for all the various buttons to be pressed at any time and to ensure that each would play its course without disrupting the entire system and main cuelist.
In the case of the interactive buttons the museum visitors would press, each of these sent a MIDI Show Control (MSC) command via a network system to the lighting controller. For ease of my organization and programming, I had all these commands come into the same MSC controlled cuelist. Then as each cue of this list was activated remotely, it would trigger a unique playback in the show file.
I had to program in all the triggers between the various cue elements. In addition, because each of the museum displays had four associated lighting buttons, I had to have each of these individual playbacks disable the other related playbacks. This meant that each playback had a macro that would disable three specific cuelists in case they were already playing.
Of course, I had to keep up with the inter-related playbacks to ensure that the correct ones were released as the related items were triggered. This allowed the user to “skip” from red to green to blue without having to wait for one cuelist to finish its playback. Also, as all this occurred, I had to ensure that the master (or background) cuelist continued to be active, and that all triggered cues would revert back to the master after one minute. Priority settings of the various playbacks helped make this possible. All this additional programming had to be taken into account, in addition to the actual lighting programming.
» Interconnectivity: Here to Stay
Although I am typically hired to program automated lights, I find myself increasingly occupied with programming interconnectivity of playbacks and thinking through how the playbacks might be used.
Regardless of the production type, there are always opportunities for interconnectivity. I find it very rare to program a show that requires only a simple cuelist, with no interactivity.
Be sure to take the time to understand the capabilities of your console and the needs of your production. Also be sure to budget time (and your rate) accordingly to program and test all the various permutations. Interconnectivity programming is fun and challenging and a pleasant addition to making lights wiggle and change colors.
