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