To my surprise, I wasn't able to find a good explanation online. Next time I have free hours(!), I should rewrite the awful discussion on the Blue room Wiki. But for the sake of giving you a prompt answer, I suggest you download the elderly ETC Expression (1) manual here, and turn to Lesson 2, Page 5-9, "Track Record Function". This discussion is a little too complete, but it will have to do for now. It also uses the terms "block" and "roadblock" interchangeably, and the latter term is not in common use. This citation certainly has a lot of examples for you, at least.
Edit: I rewrote the Blue Room Wiki entry for Block Cue.
[edited by: tbuchman at 6:36 AM (GMT -6) on Thu, Aug 28 2008]
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.
Nice example, just remember though if you have any Nps you also have to update them in the blocked cue. Adding to what Jim wrote, say you add a special (mover) that you didn't have in the 1st piece, you must add all Nps to the blocked cue for that Ch. or it will move, color, etc. when it hits the blocked cue and hits hard data. Hope this helps you some.
In a future release it will hopefully be possible to block just intensity, at a cue level. This means that you'd be able to apply an intensity-only block to a blackout cue, and leave the NPs to track into the blackout (where they can then mark or whatever).
For now the quickest way that I know of updating NPs so they don't move in the blocked blackout cue, is to go into Blind, select the cue, select the fixture(s) you've added or modified, and {Focus}{Color}{Beam}[@][Enter]
The nice thing about {Focus}{Color}{Beam} is that you can hit the three buttons at the same time with three fingers, without moving your hand too far away from the keypad. {All NP's} is fine, but it means moving further away from the keypad. So personally I find {Focus}{Color}{Beam} quicker to punch in, but at the end of the day it's just personal preference.
While the example given is a great example. I find that any cue that is exactly the way you want it, i.e. top of a scene or act, and not to change due to the fact that channels or parameters track into the cue. With the new trackback feature, we need to rethink how we trackback, not only blocking the blackout, but also the first cue in scene, lest we trackback into the blackout. As a programmer and not paying attention to the show or scenes, I tend to find where a block cue should exist is when more than half of the channels have a command. Hope this helps.
As Jay said, the blackout should be blocked. I also find if the show has "scene change states" instead of a blackout, I will apply a block to the first cue of the scene. This way any changes from the previous scene won't track forward into the next (although the will track into the sc change), and conversely any changes you make in a scene and trace / trackback through the cuelist will not track into the previous scene or scene change state.
Another handy thing to know with tracking is the [Q-only] key. Let's say channel 1 at 0 in the current cue, and you find you need to add it into this cue, but you don't want it to track forward in the cuelist. Once you have set the level for chan 1, when you goto update [update][Q only][enter] will update changes to that cue only. It won't track forward into the next and subsequent cues.
Have a play around and it will all make a bit more sense
Thanks for all of the input everyone. One of the ways I often teach tracking/blocking/trace and the impact of Cue Only is to go into blind spreadsheet for cues, make changes and watch how those changes impact the data before and after. Its a pretty easy way to become clear on the rules.
I learned on a preset desk - one concept that helped me with tracking is the idea that everything else in theatre works in tracking -
- If a director tells you to move upstage by the fireplace when you say "I'll have my revenge, then the world will suffer", you stay there until you have another instruction (eg to move downstage when you say "Sorry honey, yes I'll take the rubbish out just now"). In this example, a block cue is when everyone is supposed to run offstage no matter what, or to form a chorus line no matter what else changes...
- In sound, if you have a wind sound cue that starts at the top of the scene, and you knob it higher in Q21, it stays at that level unless you add a cue to bring it back down.
- If you bring in a set piece, it stays there until you take it out!
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.
