Rack Palette - Operators Manual - Strand Lighting

Concepts and Overview
A Note on Redundant Data
Redundant and/or Blocked data in cues is displayed like this:
or
Sometimes this is properly Blocked data. At other times it is just plain redundant.
Having redundant data in a cue is not desirable. Understanding when and why you
may want these symbols appearing in your Channel Grid or Attribute Grid will make
your life a lot easier.
Before you move on, if you're not fully familiar with the philosophy of tracking, you
may want to read the topic called Tracking first.
DESIRABLE
• When you write a Block cue at the top of Scene 2 so future editing
session on cues in Scene 1 won't track through into Scene 2.
• When you record a cue using the State option to collect the cumulative
set of data used to reproduce a cue state. You may do this at the
beginning of a scene in a linear cue list, or when you are Copying or
Moving cues within a cue list or to the middle of another cue list.
• When you have one attribute that doesn't necessarily change, but other
attributes in the cue rely on it to be in a certain state. For example, in a
CMY colour mix system, if you are fading from pure Cyan (100%, 0%, 0%)
to pure Green (100%,0%,100%) the Cyan value does not change in the
second cue. When running the second cue, you would see the Block
Symbol. This is definitely not redundant date because having Cyan at
100% is a necessary condition to making Green. If it were not there with a
Block Symbol, it would still produce Green, but the important thing to
consider is what if we change the first cue such that is does not have
Cyan at 100%. Then our second cue would not be Green. Palette
automatically marks co-dependant attributes with deltas when you are
editing so you don't have to worry too much about this. Just don't get
fussed if you do see block symbols in your attribute grid, even if you have
just perform an Un-Blocked cue operation.
UNDESIRABLE
• When you are running a show from top to bottom and attributes are marked
with block symbols, it means that those attributes will get unnecessary and
sometimes harmful fades initiated on them for no good reason. For example,
in the Tracking topic, there is a detailed example of a long Sunrise cue
followed by an actor's entrance cue. If the cyclorama channels that were
involved in the sunrise were blocked in the second cue, the long sunrise
would be quickly collapsed by the actor's entrance cue when it is executed.
• When you are copying multiple cues from one section of a cue list to another
and you use the Copy State option. This will result in many block symbols
appearing because the entire cumulative state of the cue list is recorded into
each and every copied cue. This means if you copy the sunrise/entrance
cues from the example above, you will destroy the sunrise. If you are copying
entire sections of the show within a cue list, it is best to copy the first cue in
the range using the STATE option, then all the subsequent cues without that
option. Alternatively, you can Unblock the section after you copy it.
• Putting redundant data in a cue "Because you want to make sure that if you
jump to the cue it will all be there" is not necessary. Palette always maintains
the state of the cue list during Goto's. (i.e., if you jump around in the cue list,
it will make sure that what is on stage looks just like it would if you went to the
first cue and pressed [GO] repeatedly until you got there). Some other
tracking consoles are pure "Move-Fade" boards, meaning that if you jump
Palette OS Operations Manual 10