Multiple Cue Lists for Dummies

Among a myriad of other things, I do live/corporate events.  I'll attempt to explain how multiple cue lists work for me.

Imagine, if you will, the following scenario, consisting of a stage, a cyc upstage, a podium downstage, and miscellaneous spandex-covered set pieces on the stage itself. Now imagine a lighting rig consisting of an upstage truss, a FOH truss, and miscellaneous other fixtures hung about this ballroom/arena/tent/etc (note that I'm using automated fixtures exclusively)...

The "areas" I need to light consist of the following:

1) front and back light for the stage wash

2) special for podium

3) cyc (color changing and gobo effects)

4) walls (custom gobos around the room for the corporate sponsors)

5) spandex-covered set pieces (gobo and color changing effects)

This particular setup, which is pretty common for me, would consist of 5 separate cue lists, each loaded into their own playback, with the intensity control enabled for eack of those playbacks.  This allows me to manipulate the look of any, all, and various combinations of these areas, and also allows me to fade them in and out without necessarily executing another cue.  In this situation, I likely don't have the luxury to be able to program the entire show cue by cue, and I'm usually lucky if I get some sort of script or even a rehearsal.  Having this separation allows for many different combinations of looks and keeps things flexible.  I program different combinations of palletes into presets, and place those into all the separate cue lists corresponding to the areas you see above, and I'm free to layer them on top of each other and change the looks of each area without affecting those areas I do not want changed.  I can just change one area at a time, or three, or all five, and I can go back and forth within those cue lists independently of each other, and without affecting the others (provided the cue lists don't share the same fixtures- which would be a scenario where you could use the assert command).

To simplify it even further, and put it in a different context, perhaps you have one cue list for your play or musical, one for your houselights (full, half, flash, off), and one for your worklights (full, half, blues only, flourescents, etc).

 As far as assert goes, I'll explain how I commonly use it in the above situation.  Imagine the above scenario.  We're in the middle of the show, and  my client steps up and whispers in my ear "in two minutes, we're having a surprise guest enter from the center house left door, and I'd like to spot that area".  I would proceed to take one of my automated fixtures that was being used for the custom gobos around the room, manually fade it out, and refocus it on the door for the entry.  Once the grand entrance is complete, I need to get my fixture back into its previous position and listening to that cue list again that it came from, without actually executing another cue.  The best way to do this is to call up that fixture, and assert it back into the cue list/playback that it came from.  The desk will look (trace) back to the last move information that fixture had from that cue list, and place the fixture back where it was prior to me manually moving it. 

Was any of this explanation beneficial to you?

 -Abby

Abby,

Yes, very beneficially excellent discription.  Here's a couple of follow ups:

What kind of stuff do you have on, say, your Cyc handle?  Are they a list of cues that you intend to take in order, or are they more like a bunch of looks where you load specific cues each time you change the scene?

Does one Assert channels or cues, or both?  I'd like to know more about Assert involving overlapping channels.

Thankyou much for helping me with this.  Brent

"Assert" is a cuelist-level function.

When you Assert a given cuelist, you are telling the console "This cuelist is the most important thing right now, so output exactly what it says!"

Here's an example that might help:

• I have two cuelists, A and B, containing information as follows:
• Both contain information for channels 1 thru 10 - each cuelist containing different information.
  
• "A" also contains information for 11 thru 20
• "B" also contains information for 21 thru 30
• I then run the two cuelists, each with their own Go button, and "Stuff" happens as I go.
• I then decide to Assert A:
• Channels 1 thru 10 now move to the state they would have been in if I had never touched the B cuelist, but had run A from the beginning.
• Channels 11 thru 20 do the same - although they don't actually move if A is the only thing that's touched them.
  
• However, channels 21 thru 30 are unchanged, because they have no values recorded in the A cuelist.

The "Stuff" that happens while running multiple cuelists simultaneously depends on the console and settings.

• They can be LTP:
• Hit Go on the B, and all moves in the next B cue happen, hit Go on the A and all the A cue moves happen.
• This is totally consistent with the Tracking style, and perfect for moving lights.
• However, it can be confusing for dimmers if you're not used to the concept of Tracking consoles.
  
• They can be HTP:
• Both cuelists run simultaneously, and the final output level for each channel is whichever is higher.
  
• Any moving-light aware console will only apply this to dimmer (and similar) functions, as it doesn't make sense for things like Pan!
• The cuelists could have differing priorities, where one cuelist essentially continuously Asserts over others.
• I can't really think of a use for this - I'd prefer to Assert as necessary!
  

And actually, assert can be applied to:

 A)  A Cue List

B) A Cue

C) A Cue Part

D) A channel

E) A channel parameter

This can be done via stored attributes, or it can be done directly on a fader [Assert] + [Load] or from the command line ...

Also, regardless of HTP/LTP intensity setting, only move instructions are recalled on an in-sequence go - unless the tracked values in the cue have been asserted in one of the manners above.  Assert is just an easy way to tell a tracked instruction, "if someone else took you away, you should come back to this level now."     

It is sort of the opposite of setting a priority state on a fader... where you are saying "if this fader is talking to you, no one else can talk to you."    

Does that help? 

a 

You guys are all so polite.  Rather than pointing out "hey, big fat bug here", you very nicely ask if there is a way to do something.   :-)

Jason, you should be able to put "Cue 2/0" (for example), in the execute field of your master list.  This will, in fact, work now.  However, I noticed that it doesn't use go to cue time (it bumps intensities out), and it shows"Cue 2/" in the execute field, rather than "Cue 2/0".    Having said that, once we address these two issues, this action would only drive intensities owned by Cue List 2 out, but leave all NPS where they are. 

If you want to return control of all to the master fader, right now "Release" is the only way to do that.  In 1.4.2, we are implementing the "Off" function on the faders.  This will work just like a release, but will leave the cue list loaded to the fader.  Both of these, though, involve a macro if triggered by another cue list. 

Lastly, there is "allfade".... that could be placed on a cue to drive all intensities coming from other cue lists out.

At some point, we can look to making the execute field a little more "free-form".  But for now....

You guys are all so polite.  Rather than pointing out "hey, big fat bug here", you very nicely ask if there is a way to do something.   :-)

Jason, you should be able to put "Cue 2/0" (for example), in the execute field of your master list.  This will, in fact, work now.  However, I noticed that it doesn't use go to cue time (it bumps intensities out), and it shows"Cue 2/" in the execute field, rather than "Cue 2/0".    Having said that, once we address these two issues, this action would only drive intensities owned by Cue List 2 out, but leave all NPS where they are. 

If you want to return control of all to the master fader, right now "Release" is the only way to do that.  In 1.4.2, we are implementing the "Off" function on the faders.  This will work just like a release, but will leave the cue list loaded to the fader.  Both of these, though, involve a macro if triggered by another cue list. 

Lastly, there is "allfade".... that could be placed on a cue to drive all intensities coming from other cue lists out.

At some point, we can look to making the execute field a little more "free-form".  But for now....