I'm going to give this a try, hopefully I can be clear and concise. In a tracking situation, once you bring up a light (or any other device for that matter) it remains at that level until you tell it to do something else. Think of the light switches in your home, once you turn it on, it remains in that state until you consciously turn it off. Now, let's say you're programming a dance recital (just for sake of discussion). You program all the cues in the first piece and then record a black out. Then you start up again and program the cues for the second piece. That blackout cue will only contain zero values for lights that were used in the first piece, lights who were brought up, then brought back down. Any light that wasn't touched doesn't have any information attached to it yet, because it's simply not necessary. Now let's say that you go back and add a new special into one of the cues in the first piece, you move on and forget about it. Rehearsal comes along, the new special comes up in the first dance and looks great. Then the blackout cue happens and...the special is still on in the blackout...and the second dance...and the whole rest of the show. This because it has never received any specific instruction to be turned off, because it wasn't part of the original blackout cue you recorded. Blocking is a way to prevent accidents like this. You record "hard data" (usually zeroes, but it doesn't have to be) so that any changes made to cues before the block cue are prevented (blocked) from moving forward and effecting cues later on. In this example we would record the blackout cue and then enter [CUE] # [BLOCK] [ENTER]. Now every value in that cue, even if it's tracked forward, or if there is no value, will be converted to hard data, and all the following dances are now safe from changes to the first dance. I usually record most of my blackout as blocking cues, because I figure I'm going to black for a reason, and I'm not likely to want something to track forward in the future. Hope this helps.
I am currently acting as LD and board operator for a local amateur company and I am finding that if I make a temporary live mod (to cover a cast member being in the wrong place) it is not being caught by the end of scene blackout which is recorded as a block Q. What am I doing wrong?
Are the changes you are making still manual - or are you updating them into your cue structure? Remember that blocking is an editing function - it doesn't have an impact on playback. So, if you are making manual changes, run a cue where that channel does not actually have a move instruction (a block cue doesn't necessarily mean all of the channels in the cue have a move), the light will stay manual.
The Assert function is used to make sure either some or all of the contents of a cue are replayed (including tracks). You can assert at a cue level, cue part, channel or channel parameter. Asserts are applied just like blocks. If you assert the entire cue, you'll see a capital A in the flags field. If you assert at a channel or parameter level, you'll see a lower case a in that field. Asserts applied to channels/parameters have to be updated/stored into the cue (just like any other channel attribute), unless you apply the flag in blind.
I am currently acting as LD and board operator for a local amateur company and I am finding that if I make a temporary live mod (to cover a cast member being in the wrong place) it is not being caught by the end of scene blackout which is recorded as a block Q. What am I doing wrong?
While a channel is active selected (gold border around the tombstone), it is essentially captured. Clear out the command line after your adjustment, and the channel should respond to the next move command, in your case the blackout.
Just a reminder.... a block cue does not necessarily contain a move instruction for all channels in that block cue. So, even if the channel is not selected, the light may stay at its manual levels.
Thanks for all the replies and I think I understand a bit more now :-)
In reply to Josh .... I have tried releasing the channel but it still remains in the blackout.
From reading Anne's replies it would appear that a manual change is never controlled by a playback. When plotting on a Strand 530 in tracking mode I am used to setting blackouts as XF (and these would also capture manual live mods), so am I right in saying that there is no catchall with the EOS?
Ian, the interaction between the playbacks and manual control is completely LTP. Applying an assert on your blackout cue will take your manual overrides out, provided those channels are part of the blackout cue. If they are not part of the blackout cue, you can apply an Allfade to the cue, and that will drive out any intensities coming from other sources. (Provided, of course, that the channel is not selected... in which case it is withheld from playback instructions).
Ian, assert should work just fine, if that channel is part of the cue list. When you get a minute, if you can email me the showfile, the channel and BO cue in question, I can take a quick look to see what there is to be seen. email to:
Do you still have the channel selected? If you do have the channel selected, then it is held by the channel control, therefore the Q will not drive the channel
Do you still have the channel selected? If you do have the channel selected, then it is held by the channel control, therefore the Q will not drive the channel
I have just finished a second stint as LD / board operator on an Eos and this time had less hassle with the 'blocking' command. I am wondering if my initial problems stemmed from the fact that I generated a cuelist offline so was trying to block without channels present.
