3

Preparing for Programming

There are many things that must be taken into consideration before you can begin programming. In many ways a lighting programmer is similar to an airline pilot. We are at the controls of very sophisticated equipment, often working to meet impossible deadlines, and usually not seen by the audience (passengers). Just as a pilot will not simply board a plane and take off, most automated lighting programmers do not just walk up to a console and rig and begin entering cues into the desk. There is a certain amount of preparation that must be completed prior to taking off and building cues. Once the cues are built, an efficient saving routine must be followed to ensure all the hard work is protected.

Fixture Setup

Before the lighting rig is set up, you need to be sure to communicate a few things to the crew. Programming will proceed smoothly if the fixtures are all hanging in the same direction (where applicable). If you have a batten with six wash lights on it you want to make sure all the fixtures are oriented in the same direction. If two of them are 180 degrees off from the others, then when you tilt them all together, four of them will move upstage and two will move downstage. In addition, as most fixtures use wheels to bring in colors and effects, if they are facing different directions, these wheels will appear to be coming from different sides of the stage. The best method to ensure the fixtures are facing the same direction is to place them all with their LEDs or data cables pointing in the identical direction.

We live in an age when software makes everything function. Fixture manufacturers continually upgrade their fixture software to make improvements and add features. If your fixtures have different versions of operating software, then they might behave differently. For example, a hard edge fixture might have an update to its software allowing the gobos to rotate at a faster rate. If two of your fixtures have an older version, then they will not be able to match the rest of the rig. Asking the crew to ensure that all fixtures have the most current operating software before the rig is assembled will help reduce problems later on.

Most fixtures have a method of inverting pan and or tilt via dipswitches or menus. Likewise most moving light consoles have the ability to assign these settings from the console. It is best to have the crew turn off all pan and tilt inverts at the fixtures and allow the console to perform this function. If the function is assigned at the fixture, then this setting must be remembered if the fixture is ever taken down and replaced. If there is a general rule that all fixtures have pan and tilt settings set to off then the chance of error is reduced. In addition, some fixtures may have additional settings to allow for faster color changes or mirror movements. Once again you will want to assign all fixtures the same settings; otherwise, problems will develop as you program.

The Console

As the programmer, you are responsible for the operation of your console. You should be aware of not only how the console functions, but also what is required for your production. For instance, if you are going to use the Society of Motion Picture and Television Engineers (SMPTE) timecode, you will need to specify to the sound crew what type of connector is required for the console’s input. In addition, you need to be aware of the version of software loaded in the desk. If you simply turn on the console and begin programming, you might find the console’s fixture library does not contain the fixtures you need or, even worse, you might run into some console bugs. Just as fixture manufacturers are continually updating their software, so are the console manufacturers. I always go to the website of the console manufacturer and download the latest software as well as the list of changes and/or bug fixes. I then read all the documentation and determine if upgrading will be beneficial. Many programmers find a version of software they are comfortable with and do not upgrade beyond it until absolutely required. Remember everyone on the show will be looking at you when something goes wrong with the console, so you should load the version of software you think is best. Good programmers carry with them the version of software they intend to use on the console and do not count on the lighting supplier to have the console preloaded with whichever version. It is also good practice to not change console operating software during the run of a show unless absolutely necessary (for example, bug fixes). Wait until next season to upgrade and follow that old saying, “if it ain’t broke, don’t fix it”.

When specifying the console, you should also specify what accessories you will need. Never assume the lighting provider will supply a keyboard, trackball, monitors, etc. If you intend to have video graphics array (VGA) monitors to connect to the console, be sure to place them on the order. If you know that production table space is at a premium, you might need to ask for flat screen monitors to save space. It is best if you can plug the console into an UPS and have additional front of house (FOH) power for anything else you might need (laptops, cell phone chargers, etc.). In addition, make sure that nothing else gets plugged into the UPS except the console. You do not want the LD’s coffeepot killing the power to the desk in the middle of programming. Speaking of which, the FOH area often becomes your home during the production period. I always ask for a comfortable chair or stool, as I do not want to sit on a road case for a week (or even one day). There is nothing worse than being uncomfortable 14 hours a day. Other items you might need at FOH include floppy disks, little lights, audio playback (jam box), and/or video equipment (see Table 3.1).

Table 3.1 Suggested Front of House Items

Many productions require a backup console. Usually the console will be loaded with the final show files and be standing by in case something happens to the main console. In some cases an A/B switch is used to toggle the DMX lines should the master console go down. Oftentimes the testing of the backup console gets put off till just before it is needed.On the day of load in, it is important to open the box of the backup and test to make sure it can load and save a show. This way if you ever need to change out, you know it is in working order. When presented with the need for full redundant tracking backups, be sure to test all Musical Instrument Digital Interface (MIDI) or Ethernet connections to ensure the tracking is functioning properly prior to the programming period.

Most consoles require a certain amount of setup before you can begin programming. While the rig is going up, take the time to create screen views, layouts, macros, etc. In addition, go through the other setup options to define other specific options you need for your show such as SMPTE or MIDI. Prepare as much as you can before arriving at the show site. Either use a console in the shop, or the offline editing software of your console for preparations.

Preparing the Patch

One of the first things that must happen when preparing a show is patching the console. If the patch is incorrect, then the console will be unable to communicate properly with the fixtures. Most fixtures communicate via DMX-512, the universal lighting language. Within this network of data each fixture is assigned a DMX start address that must be entered into the console. Sometimes the fixture addressing will be determined prior to the patching, sometimes the patching will dictate the addressing. This will depend upon the size of the show, the crew chief, the LD, and the programmer. Even before you begin patching you have to understand how DMX addressing works.

Let’s say you have a rig of 6 hard edge fixtures and 6 wash fixtures. The hard edge fixtures each use 18 channels of DMX and the wash fixtures 16 each. This means you will be using a total of 204 DMX channels. You now need to determine the start address for each fixture. There are two ways to calculate this. One way is to sit down with a notepad and calculator and do the math. The other method is to patch them into your console or its offline editor (see Table 3.2). I prefer to use the consolemethod, as most consoles do not allow overlapping addresses (they do not allow for mistakes that could be made with a paper and pen). Also, once the information is in the desk, you can print the patch and use the printout to address the fixtures correctly.

If the desk is capable of more than one universe of DMX, then fixtures can be placed on the different universes. For example, if you have fixtures on the truss and fixtures on the floor, you might want to run a separate data line to each location. You could then plug the truss fixtures into universe 1 and the floor fixtures into universe 2. Since each universe is its own set of 512 DMX channels, you can address your fixtures within their own unique universe. So you might have two fixtures with the same DMX address, but on different universes. Of course, if you have a large number of fixtures in your rig, then you will have to make use of the different universes.

It does not take long to utilize all 512 channels, as most modern fixtures use 16 to 24 DMX channels. If your fixtures use 20 DMX channels each you can only patch 25 fixtures per universe (20 × 25 = 500). When determining the patch, you will want to make sure the point you change universes is a logical one. For instance, let’s say you have a front truss and a back truss each with 15 fixtures using 20 channels each. You would not want to put 25 fixtures on one universe and 5 on the other, as one of the trusses would require two separate data runs (one for each universe). You would be better off to patch 15 fixtures to each universe and run one data line to each truss.

Numbers Everywhere

Depending upon your desk, you might have a host of numbers assigned to your fixtures. Most consoles allow the programmer to define the “handle” for the fixture. The handle or user number is the number the programmer uses to select and program the fixture. This number is usually different than the actual DMX address of the fixture. This is because you generally want to number the fixtures in a linear order. In addition, you might choose to number them in a method that makes selecting them quicker and easier. One example would be to number the fixtures on the downstage truss 1–6 and the fixtures on the upstage truss 11–16. This way the user number reminds you of the placement of the fixture (downstage fixtures are less than 10 and upstage fixtures are greater than 11). Some programmers like to number according to fixture location, others according to fixture type. You might make the hard edge fixtures 21–28 and the wash fixtures 31–42. Another trick of the trade is to begin each sequence of numbering with the digit 1. For example, if I have 48 fixtures with 8 on each of 5 trusses, I might number them as 1–8, 11–18, 21–28, 31–38, and 41–48. You will notice I am not using the digits 10, 20, 30, and 40.

Most programmers find it easier to remember which fixture is which if they begin the numbering at 11, 21, 31, and 41. This is because we can look at any of the five trusses and quickly determine the first, second, third, fourth, etc. fixture. If we had to deal with a zero, it would be more confusing to glance at a piece of truss and select the fifth light from stage right.

Once all the user numbers are assigned and the fixtures are addressed, then the DMX addresses in the patch can be forgotten. As the programmer, you will only be working with the fixtures via their assigned handles. These numbers should be given to the LD and the crew so that everyone will refer to the fixtures via the same numbers. If you have a problem with fixture 85, you want the crew to know exactly which light you are talking about. When drawing a plot, you should put both the handles and the DMX address on the plot so that everyone can glance at the plot for the information they need (see Figure 3.1).

When working with an LD, it is important to decide who determines the handle numbering. Some LDs will dictate what the numbers will be, but most allow the programmer to make this determination. In this case the programmer will need to notify the LD of the numbers that have been assigned. The LD can then enter these into the plot and paperwork and use the numbers when calling out cue data to the programmer.

After the patch is complete, it is time to test. If the fixtures are set up incorrectly, then the response from them will either be incorrect, erratic, or nonexistent. Once the entire rig appears to work, you need to check each fixture to ensure they are set to the correct address. If you simply select all fixtures at 100% to confirm they are working, you may not know that two of them have the same address. It is imperative that you cycle through each fixture one at a time to confirm they are responding to the correct user number and DMX address you have assigned in your patch. You might also cycle through all the gobos to make sure all fixtures have the correct patterns in the same slots (especially if the LD has requested custom patterns).

Groups

Once you have your console and fixtures operating correctly, the next step is to begin setting up the specific programming tools for your show. A good starting procedure is building fixture groups. A fixture group is a simple console function that allows for instant selecting of specific fixtures. Many moving light consoles will premake groups by fixture type (all brand x wash lights, even brand x wash lights, odd brand x wash lights), but there are many others you will want to create. Take a look at the show you are about to program and decide how you are going to break down the rig for quicker programming. For example, you might make a group with all hard edge fixtures on the upstage truss, another for the downstage truss, and another for the floor fixtures (see Table 3.3). By creating these groups prior to the programming session, you will be able to quickly select a bank of lights for specific programming purposes. In fact, many groups can be built using an offline editor or a desk in the shop.

Protecting Your Work

As a moving light programmer, it is your duty to safeguard the lighting console data. I have seen consoles crash, show files become corrupt, floppy and hard disks fail, and even intentional sabotage. Lighting programmers must ensure that the data they create is protected so that the lighting of the show is not lost or damaged. Saving should happen from the moment the console preparation begins until after the final performance.

When you are hired to program a show, you are not just responsible for the entry of the data into the console, but also for the protection of

that data. If data is lost due to console crashes, storage media failure, or operator error, it is up to the programmer to reenter all lost data. This can lead to a tremendous loss of time and creative energy. Of course, there are the rare instances where a cue can be built better the second time around, but usually you want to avoid having to rebuild cues. Lack of proper saving can add up to thousands of dollars for the producers. If reprogramming is required, someone has to pay the bills and this is one of the quickest ways to not get rehired.

The many consoles on the market use just a few methods of storing their data. Older controllers might use a random access memory (RAM) card, while newer consoles use hard drives, Zip disks, and even compact disc-rewritables (CDRWs) (see Figure 3.2). No matter the media, it is important to remember that all storage devices can fail at some point. Whichever media your console uses, you should always make multiple backups on various types of media. Even if your console has a hard drive and can make regular saves in the background, it is highly advised that you archive your work on other devices (floppy disk, CD, Zip, etc.).

It is very important to design a saving regimen that works for you and your console and stick to it so it becomes habit. For example, when I am programming a show, I will save my work on the native storage (hard drive or floppy) as well as make backups onto additional floppy disks. I then make off-site copies daily so I can refer back to any day’s work.

Let’s say the worst thing happens — your console crashes and erases everything since your last save. This could mean you have lost hours of work, unless you are diligent about saving often. For instance, you are working on a concert tour and you decide to save as you finish programming each song. If each song averages three hours of programming, then you will be in big trouble when data is lost. If you instead save several times during the three-hour period, then you will not feel so depressed when something goes wrong. Sometimes it can be difficult to follow this regimen as you and the LD will get into a rhythm and want to keep pressing forward. The longer you proceed without saving, the more you are living on the edge. Try to force yourself to make a point to save often (especially after creating a long sequence that was difficult to program). It is much better to wait a few minutes for the backup than to have to start over from scratch. Another rule I personally follow is to never walk away from a console without first saving the show. Whether I am going to the restroom or just up on stage for a moment, I will save my work to ensure that nothing occurs while I am away from the desk.

Now that you see the importance of saving often, there are more guidelines to follow. No matter the storage media, it is important to save to different files or disks. If you save often but always to the same floppy disk or the same file on your hard drive, then you are still living dangerously. What if that file or floppy becomes corrupted or fails? Then even with your diligent saving, your work could still be lost. For consoles that save directly to floppy disk without a hard-drive, I suggest the following “leapfrog” method of saving your show (see Figure 3.3). Start with 3–5 disks and label these A, B, C, D, and E. Stack them in alphabetical order. Each time you save, take the disk from the top of the stack and save your show. Then on the next save remove the current disk and place it on the bottom of the pile.

This way if something happens, you have 2 to 4 previous copies to refer to. If working with a console that uses a hard drive for storage, then save to different files on the hard drive. Try to name the file so you do not get confused as to which file is the latest (although you can usually read the time and date stamp of the saved file). For example, you might save your show files as “myshowA,” “myshowB,” “myshowC,” etc. Also, it is a good idea to make periodic archives to another media besides the hard drive in the event of a hard drive failure.

Once you have completed your programming session each day, it is very important to make and store multiple copies of your current show file. If you simply save it on the console and come back the next day, then what happens if the console lost your show file (or the console is missing, etc.)? I usually make 2 copies for myself (and keep my last 2 disks in the leapfrog set as well). In addition, I will make a copy for the LD and a copy for the crew chief. By distributing multiple copies of the show, I have ensured that should something happen to me (I walk though a highly magnetic zone or am hit by a truck, etc.) then someone else will still have a copy of the show data. Also, I will then make a copy of the show file onto my laptop when I return to my hotel room (or on-site if I have my laptop with me at the console). Making a separate folder on your computer for each day’s work ensures you always have an older copy of the show to refer back to. Once the show is complete, you can delete all but the final show from your computer (unless you like to hang on to all that data).

Many programmers use even stricter methods of protecting their work. Think of your saving method as insurance. Spend as much time saving as you feel you can afford. Keep in mind that the more you spend the more you will be protected in the event of a catastrophe (but you do not want to spend all your time waiting for the desk to write to disk). I would not suggest saving after each cue is built, but I have seen programmers who save nearly as often. Some people will save thirty times a day to two boxes of disks and others will save five times to three disks. The most important choice is to find a saving method that works for you and to use it consistently.

Always Be Prepared

Each new production you program will present its own unique challenges. This is one of the reasons that working as an automated lighting programmer can be so much fun. Proper preparation for each new endeavor will allow you the freedom and piece of mind to concentrate on making the current production the best it can be. From ensuring the fixtures are operating correctly to setting up the console in an efficient manner, every bit of preparation will undoubtedly help the show. Many moving light consoles will allow you to import your common palettes and setups to make some of the initial setup even easier.

In the future, when DMX is replaced by a network friendly protocol, each fixture might tell the desk what line it is plugged into and what its functions are. Then the programmer will only need to assign a user number to the fixture and begin programming. Some manufacturers have already incorporated this functionality using DMX via talkback and have consoles that can remotely address the fixtures according to the patch in the desk. However, for the foreseeable future programmers will have to patch their fixtures into the desk by hand as part of their normal preparations for a show.

By preparing for each production with proper planning for the front of house, fixtures, console setup, patch, and groupings, you can begin concentrating on your programming sooner. As the preparations become habit, you will find it a simple process to specify what is needed as well as to prebuild or import data into the console. Much of programming is about consistency and a consistent setup procedure helps produce an efficient programming experience.