26.05.2014 Views

Download a PDF - PLSN.com

Download a PDF - PLSN.com

Download a PDF - PLSN.com

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!