6

Advanced Programming

The many facets of automated lighting programming allow for different levels of programmers. Very accomplished programmers may never utilize show control or visualization, while others will depend upon them during nearly every production. Budgetary and time constraints often dictate the use of advanced programming functionalities, while others will use these concepts to further the capabilities of the lighting. It is important for an automated lighting programmer to be aware of the advanced programming techniques that he or she might encounter.

Visualization

Many years ago I attended a lighting seminar in New York. While there, I met another student who told me about a new product about to be introduced at the upcoming Lighting Dimensions International (LDI) tradeshow. He said some friends in Canada had developed software that allowed them to program their moving lights by looking at a representation of them on a computer screen. This software would allow them to preprogram in a virtual world and then later plug in the real fixtures. They hoped their new idea would start a revolution in the automated lighting world. This software quickly grew into the industry standard visualization tool we know today as WYSIWYG (what you see is what you get).

There are now several different brands of lighting visualization software, and even some lighting consoles with built-in or proprietary software. All of these programs serve one basic purpose, to allow you to see the final result of your programming data without attaching genuine fixtures.

How It Works

Visualization software in its most basic form is a virtual lighting rig that you program using any standard DMX console. The software does little more than emulate what a real lighting rig would do, thereby allowing programmers to use their console to create or edit a show without an actual lighting rig. All programming data and cueing remains in the lighting console making the transition to a real lighting rig very simple (just plug in the DMX). Early versions of the software were simple wire-frame drawings of the fixture’s output, but now sophisticated rendering systems and even 3D environments are commonplace. Visualization software can do many things to aid a designer and others involved with a production; however, for the purpose of this book I will try to focus on the programming aspects alone.

Benefits

One of the biggest reasons to use visualization software is the substantial savings involved. If you can spend half of your programming time in the virtual world, then the production will save thousands of dollars. The cost to rent a venue, hire a crew, rent equipment, etc. is usually much higher than the use of a console, computer, and software. This means that quite often your programming time can increase, allowing more flexibility and creativity in your work. In addition, the FOH area can be anywhere you like. You can work in a comfortable environment at any hours you and the LD desire.

Building cues while staring at a computer screen also has other advantages. I usually find the programming time with visualization a great period to “learn” the rig, the LD’s intentions, and the production details. If you discover that the downstage truss fixtures will not reach all the needed locations, you can easily move them to a new position without calling in the crew. In addition, this period is often used to setup everything in the console prior to programming (palettes, groups, colors, SMPTE timecode, etc.).

Programming

Programming with a visualizer is no different than programming with an actual lighting rig. All the functions of your console are still available to you. However, there are many things you must consider when working in a virtual world. Most of the visualization programs work very hard to reproduce exactly how real fixtures output, but there are often differences. In the virtual world things often move at different speeds than in the real world. You might find that your fixtures can move from stage right to stage left in half a second on the computer screen, but the actual fixtures are not able to move as quickly. When programming with a visualizer, it is very important to understand that you will probably need to touch up your cues. In addition, most modern fixtures have automated functions such as strobing or gobo wheel rotations. Often these speeds will also be different on screen than with a real fixture. That perfect strobe setting that flashed with the musical beat during preprogramming might turn out to be twice as fast with the actual rig. It is a good idea to have one of each fixture in your rig hooked up live while working with a visualizer. This way you can check the colors, speeds, etc. on that one fixture and learn how it differs from the computerized version.

Most automated lighting consoles make use of palettes (also known as position memories, presets, focus points, etc.). These are references to specific values that can be recorded into cues. If you change the value of the reference, all your cues using it will also update. Palettes become extremely important when programming with a visualizer. There are too many real world factors to enable you to take a show programmed virtually and run a perfect show without updating any information. For example, a slight deviation in the angle of the fixtures can cause them to project in the wrong positions. The most important thing to remember when working with a visualizer is that it can only simulate the real world and you will need to make changes accordingly.

Cueing

The ability to structure your show is one of the most valuable benefits of working with a visualizer. Frequently rough cue ideas are created virtually and later made complete with the real fixtures. The rough cue data, however, will act as a placeholder of the LD’s concepts, and, more importantly, the timing of the show. Expect to make changes to the look of a cue simply because it appears much different in reality versus the computer screen. Also when working with timecode, visualizers provide a superb opportunity to enter cue times and perfect the cueing construction.

Two-Way Communication

Most visualizer software packages have a method of communicating with supported consoles. This allows an LD to create his drawings and paperwork within the software and then send the patch information to the lighting console. In addition, oftentimes you can use the computer mouse to point to a location on the virtual set. Not only will the fixtures point to this location, but the pan and tilt information will also appear in your console for recording to cues or palettes. We are just now beginning to see the “Holy Grail” of lighting visualization: blind or preview capabilities. This function allows programmers to build or preview information on the visualization software without outputting DMX to the lighting rig. During a show, the programmer can modify an upcoming cue while looking at a representation of it.

Program Anywhere

Thanks to a group of Canadians emulating real fixtures, the automated lighting industry was revolutionized. There are many visualization studios around the world where an LD and programmer can simply walk in and begin working. In addition to reducing costs and aiding in cue creation, visualizers are a great learning tool. Students can now learn the functions of a console and fixtures with much less expense. Many console offline editors work directly with a visualizer, eliminating the need for a console. I enjoy programming real fixtures as much as I enjoy playing “lighting video games” with a visualizer. Imagine sitting on a plane, preprogramming your show as if you were sitting in a venue with a full lighting rig. Trust me, it is a lot of fun (especially during turbulence)!

It’s Time For Timecode

Many productions require the lighting to be perfectly synchronized with the audio or video elements. While this can be achieved manually with a good operator, the best method is to use some sort of show control to automate the lighting cues. One of the more common approaches is to use a form of timecode.

The History of Timecode

In the days of film (before videotape), audio synchronization was achieved mechanically. The film itself and audiotapes had sprocket holes that would allow for perfect synchronization of the two sources. When videotape was developed without sprockets, an electronic method for synchronizing was created. In 1967 the Society of Motion Picture and Television Engineers developed SMPTE timecode. This standard was based upon an eight-digit twenty-four-hour clock.

In addition to SMPTE, there are several other types of timecode including MIDI timecode (MTC). MTC is very similar to the SMPTE timecode, but in a different protocol. Depending on your production and your lighting console, you might talk about SMPTE but actually use MTC. Throughout this book when timecode is mentioned, it can be any of the actual forms.

Defining Timecode

The first two digits represent the hour (0–23), the next two the minute (0–59), then the second (0–59), and finally the frame (0–xx). Notice I did not give a range for the frames. The frame rate will change depending upon the standard used. Currently there are four typical frame rate standards, each with a different value of frames per second or fps (see Table 6.1).

Table 6.1 Common Frame Rate Standards

SMPTE 30 is the original SMPTE standard often used in the audio industry. NTSC 30 or SMPTE 30 drop frame is mostly used by the NTSC video industry. This frame rate is based on 30fps, but two frame counts are dropped at the start of every minute, except for every tenth minute. EBU is commonly used in Europe by the PAL video industry, and FILM, as the name implies, is used by the film industry.

I do not want to scare you by going into in-depth explanations of how timecode functions in the binary and linear worlds. However, there are many books and websites dedicated to the subject if you are interested in learning more.

Timecode and Lighting

Imagine building a very complex lighting show that executes 1200 cues in 3 minutes. These cues coincide with specific music notes of the audio track. At the very moment the short production is concluded, the show repeats again with the same perfection. This type of accuracy would be near impossible for a human operator to obtain, so another form of synchronized triggering is needed. Synchronizing your lighting to an audio or video track is a very simple process involving timecode.

The first step is to decide that you need to use timecode to trigger your lighting. Make sure your production has elements that will generate the timecode. For example, if you are working on a live play, you probably will not have a recorded source that the actors synchronize to. If you are working on an dance show where each number runs from a digital audiotape (DAT), then you have a sync source. You will need to work with the audio crew to ensure they provide you with the type of timecode required for your console.

Now that you have the timecode source confirmed, you can build your lighting cues as you normally would. After the cues are in the console, you can go back and assign a trigger time to each. Many consoles allow you to “teach” the trigger times to the cuelist. When using a “learn timing” method, you will playback your audio or timecode source and then simply press your console’s GO button at the appropriate moment in the music. The console will then insert the timecode value for that moment into the trigger time for the cue. Later, when you replay your timecode source, the cues will playback at the exact time locations when you pressed the GO button. You have essentially recorded the timing of your GO presses into the console. I suggest reading your console’s manual to determine exactly how to get the timecode times into your cuelist.

Changing Time

Table 6.2 represents a cuelist with timecode trigger points for five cues. By looking at the differences in the numbers, you can gain a lot of information. For example, the last cue happens 2 minutes 41 seconds and 3 frames after the first cue. You can also see there is a little less than 5 seconds between cues 2 and 3. Much information can be gathered by looking at the cue triggering times.

Let’s say you replay your cuelist and the lighting for cue 4 is not synchronized with the explosion sound on the audio track. You will first need to determine if the lighting cue occurs too early or too late and then modify the trigger time. Determining how much time to edit can be difficult, but here is a rough guide. Do not begin by editing single frames (unless the cue is just really close). Think of the frames in easier editing blocks. For instance, when using 30fps remember that 15 frames is half a second and 7 frames is about a fourth of a second. I generally begin by editing within half a second and then move to smaller increments.

Hidden Dangers

Right now you might be thinking that working with timecode is a much simpler process than you first thought. You are correct; however, there are some dangers to lookout for. First, you need to make sure that your timecode source does not change once you begin adding timing to your cues. If the times that reference specific points in the audio track are suddenly off by 1 minute 13 frames, then you will have to edit all the times in your cuelist. I have seen many cases where the audio crew will rerecord the tracks and change the timecode values, or maybe they discover they are sending the wrong format and change their settings. When these things happen, you can spend hours editing cue trigger times.

Another element you must consider when using timecode is that there is now an input to your lighting console. If your show begins and you forget to turn on the timecode, then the audio will begin, but the lighting will not. On the other hand, if you leave your timecode input on while you are editing cues and the sound guy decides to press play on the DAT, then your console might jump to an unexpected cue. You need to take care to minimize timecode problems.

Back to the Future

Luckily working with timecode and lighting is usually a very simple process. Many programmers become nervous and concerned the first time they hear the show needs to be triggered via timecode. However, as you can see, there is not that much involved. I will warn you, though, that often LDs love to use timecode because they know that cues can be triggered with every single audio note, and you will find yourself building longer cuelists. I see this as a good thing, as it just means more programming time at the lighting console.

The Magic Of MIDI

There comes a time in every automated lighting programmer’s career that they will be asked to use MIDI or MIDI Show Control. MIDI is an acronym for Musical Instrument Digital Interface. It was developed in the early 1980s as a standard method for electronic musical equipment to pass messages to each other. In the early 1990s, many manufacturers of professional entertainment equipment created a special subset of MIDI with unique commands relating to entertainment productions. This new protocol was referred to as MIDI Show Control (MSC). Many automated lighting consoles implemented MIDI and/or MSC to allow remote triggering of lighting consoles and other devices. The following is a broad overview of MIDI and MSC uses as related to automated lighting programming. Many existing books and Internet resources further explain MIDI and MIDI Show Control in-depth.

Lighting Applications

Generally an automated lighting programmer will not need to be an expert with MIDI and MSC. However, there are four basic uses associated with lighting programming that you must be aware of. The first two relate to console redundancy. Many designers insist on a backup lighting console in the event of a failure. Consoles connected via MIDI or MSC often have the capability of real-time playback tracking or complete redundancy. With real-time playback tracking, the main console will send MIDI or MSC commands to the second console ensuring that both consoles are in the same state of playback. Any new programming information will exist only on the main console. On the other hand, complete redundancy uses MIDI or MSC to send every keystroke from the main console to the secondary console. In this scenario, both consoles will always maintain the same state as they are performing identical key presses.

The next two uses of MIDI or MSC commonly used by automated lighting programmers are for interaction with other devices within the production. For example, the automated lighting console might send playback commands to a conventional lighting console. In addition, a lighting console might use MIDI or MSC to trigger a wide assortment of devices such as audio, video, automation, scenic elements, etc. In the same manner, MIDI and MSC can be used for triggering an automated lighting console from show control computers or other devices.

MIDI Notes

MIDI in its simplest form is a networking protocol that allows multiple devices to communicate with simple commands. The command set includes note-ons, note-offs, key velocity, pitch bend, and other methods designed for controlling a synthesizer (see Table 6.3). Sometimes basic MIDI is referred to as “MIDI Notes” due to its musical structure.

Table 6.3 Basic MIDI Commands

 

To aid with large configurations of equipment, MIDI specifies 16 discrete MIDI Channels. This enables a single cable arrangement to control up to 16 different devices at once. The model of MIDI Channels is similar to the concept of a DMX address. Each device is assigned a MIDI Channel number and will listen only to commands sent to that channel. In this manner many devices can be connected in series, yet only respond to commands specific to each device. For example, a show control computer might send commands to an automated lighting console, a conventional lighting console, and an audio desk. All devices will receive the same data from the show control computer, but respond only to their unique commands as defined by the MIDI Channel. When setting up your console to respond to MIDI information, you will need to assign a MIDI Channel number to the console. If your console will be used to transmit MIDI information to trigger other devices, then the output MIDI Channel will need to be defined with each command. Refer to your console’s documentation for further details on defining MIDI Channels.

MIDI Show Control

As the use of MIDI grew in the 1980s, many entertainment professionals saw the need for a specialized subset of MIDI. They developed a new standard known as MIDI Show Control. The command set includes load, go, stop, cue number, cuelist number, fire macro, etc. In addition, specific subcommands were developed for industry-based command structures. Each command format of MSC consists of its own types of commands related to the industry type. Some of these industries include: lighting, audio, pyrotechnics, and video (see Table 6.4).

Table 6.4 MIDI Show Control Command Formats

In a similar method to MIDI Channels, MSC defines a Device ID for each unique device. Again, this setting allows each device to receive all MSC commands but only respond to those intended for its unique Device ID. When setting up your console to respond to MSC information you will need to assign an MSC Device ID to the console. If your console will be used to transmit MSC information to trigger other devices, then the output MSC Device ID will need to be defined with each command. Refer to your console’s documentation for further details on defining MSC Device IDs.

MSC transmits both commands and command data (see Table 6.5). For instance, an MSC message might send the equivalent of “Device ID 2 Lighting General Format Go Cue 2 Cuelist 7.” If a device sends this information to your console, it should trigger the second cue of the seventh cuelist. Unfortunately, many console manufacturers have chosen not to fully implement MSC.Your console might ignore the cuelist number portion of the command and instead apply the message to the currently active cuelist (or even to all cuelists). It is extremely important that you read and understand the console’s MSC implementation. With a properly configured console, MSC receiving functionality should be relatively simple.

In addition to receiving MSC commands, many lighting consoles also have the ability to transmit MSC messages. Depending upon the functionality of your console, this message might be editable. However, many consoles simply implement MSC to send commands mimicking console activities. For example, if you press GO for cue 2 of cuelist 7, the console will send this information out to a predefined Device ID. Other lighting consoles have methods to send unique MSC commands in the same manner as lighting cues. This ability allows the lighting console to behave as a show control computer by triggering various devices through the use of MSC. Quite often a substantial understanding of MSC (hex codes, commands, formats, etc.) is required. Very few console manufacturers have spent the time to create a user-friendly user interface. Luckily there are many books and Internet resources available regarding MIDI and MSC.

Be Prepared

Unfortunately, most lighting consoles have adopted a rather poor implementation of MIDI and MSC, thus requiring programmers to be familiar with hex codes and other technical jargon. Since MIDI and MSC are rarely used beyond simple triggering or redundant control, manufacturers of lighting consoles have not put much effort into creating user-friendly interfaces. It is essential that a lighting programmer study the user manual of the console to determine exactly how MIDI and MSC function within the console. Fortunately, however, MIDI and MSC use rarely appears as a last minute surprise, thus allowing programmers an opportunity to analyze their console’s implementation.