Automated Lighting Programmers must be aware of many concepts when programming a show. One of the most important concepts with any automated lighting console is known as tracking. I have written many articles and even devoted a chapter in my book (The Automated Lighting Programmer’s Handbook) to explain this concept, as it is essential that programmers completely grasp the tracking idea. Once tracking is understood, the ability of the programmer grows tenfold. However, there is another concept that goes hand-in-hand with tracking known as state.
A Little Background Please
In order to fully understand the idea of state, we must first look back at tracking. Tracking on an automated lighting console simply means that the cues you write only store the changes you have made for your fixtures and not ALL parameters of all fixtures. Data that is not changed from one cue to the next will remain the same, since no new values are present. This is where the tracking comes from.
In Figure 1, you can see that fixtures 3 and 4 have no data recorded within Cue 2. So their current value from Cue 1 will track into Cue 2. In Cue 3, they each get a new value and the previous values are no longer tracked.
So What About the State?
Lets continue to look at Cue 2. The actual cue only contains data for fixtures 1 and 2, so this is the cue data. However, Cue 2 on stage looks much different than just fixtures 1 and 2. Due to the result of tracking, Cue 2 also results in fixtures 3 and 4 doing something. The state of Cue 2 is the data recorded within Cue 2 plus the results of data tracking into this cue. It is vital that programmers understand the difference between Cue 2 and the state of Cue 2.
Have a look at Figure 2. Now you can see the difference between the state of Cue 2 and the recorded values within Cue 2, because I have displayed the tracking values in blue-colored text.
Not On My Console
You might be asking yourself why you cannot find a mention of the word “state”? in the user manual for your console of choice. Well, this is because the terminology is different on different consoles, but the concept is there; I assure you. Some consoles simply refer to state as tracked values, status, or resulting values. In addition, most consoles will display the tracked values (state) in a specific color within the screens. As always, it is important to read your user manual to determine how your console refers to state. Some consoles even let you toggle on and off the viewing of the state of a cue.
I Understand; Now What?
With an understanding of the concept of state, there are many tools that an automated lighting programmer can put to use. First and foremost, it is because of the state of a cue that it appears as it does on stage. So if you play a cue and it does not appear as you expect, you should ask yourself if this is due to the state of the cue.
For example, imagine you record Cue 5 with all fixtures in a particular gobo and no color. Then you play the cue back and see that the gobo looks good, but it is a green color. You should be able to understand that this is due to the state of Cue 5. You more than likely did not record a color, thus the green color has tracked in from a previous cue. You can quickly solve this by adding in a white color value for your fixtures in Cue 5.
When you are editing cues, you might open or load a cue to view it on stage. If you simply view Cue 2 from Figure 2, then you will only see fixtures 1 and 3. If you view the state of Cue 2, then you will see fixtures 1-4.
Most consoles have a method to view or load a cue for editing. Usually there will be an option or selection that you can choose to either load the cue normally, or load the state of the cue. By loading the state of the cue, you get what it actually looks like on stage instead of only what has changed within that particular cue. The decision as to when to load the state versus the cue is one that you will have to make on a case-by-case basis.
The Power of Copying State
One of my favorite uses of state is to copy values or cues using state. In Figure 3, I have shown the difference of copying Cue 2 to Cue 4 with and without state. When Cue 2 is simply copied to Cue 4 (without state) then Cue 4 looks nothing like Cue 2. This is because values from Cue 3 have tracked into Cue 4. However, if Cue 2 is copied to Cue 4 with state then it will look identical on stage to when Cue 2 was first played.
I find copying with state an essential tool when working on any production. Often an LD will ask for a cue to be repeated later in the list. I may or may not remember how I built the original cue, but it does not really matter. As long as I copy the original cue using state, then I know that my copy will appear exactly as the original.
Keeping the Peace with State
Most tracking consoles also contain a function that allows programmers to record a change to a cue, insert a cue, or delete a cue without affecting the state of the next cue. This is often known as “cue only” or “track forwards off.” Figure 4 shows the insertion of a Cue 2.5 where the values of Cue 3 shown in red are the result of tracking before the insertion of Cue 2.5. If Cue 2.5 is inserted between Cue 2 and 3, then Cue 3 would track the values from Cue 2.5 instead of Cue 2 and look very different. However, by using “cue only” to record Cue 2.5, then the console automatically took the results of Cue 1 and 2 tracking into Cue 3 and hard-coded this information into Cue 3. This way Cue 2.5’s changes only affect Cue 2.5 and do not disrupt the tracking information that existed before Cue 2.5. The state of Cue 3 remains unchanged by the insertion of Cue 2.5
By using the concept of “cue only” or “track forwards off” you can safely make changes within your cuelist without disrupting the previously built cues. For instance, if you suddenly were to delete Cue 1, then the rest of your cuelist will be different, as certain values would have nothing to track from. However, if you activate the cue only function on your desk as you delete Cue 1, then the tracked information will become part of Cue 2 and the list will not be affected by the deletion.
Put Your State to Work for You
The power of state within your cues and programming procedures can save you hours of work. By understanding the differences of a cue with and without state and by using the tools of your console, you can easily view, record, extract, copy and delete data without making huge changes to the look of your show. As you learn the state related functions of your console, you can apply these tools to increase your programming speed and efficiency.
