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

"Was any of this explanation beneficial to you?"

Excellant description.

Question now is, can you do multiple cue lists on submasters on an Ion ?.

Steve B.

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....

Look, I promise I want to learn this stuff but I still don't really get why I need them as a default.  I think I could do all of Abby's stuff with Subs, Direct Selects and Palettes.  She never did answer my question about what is on her Cyc handle.

Richard, are your cues a sequence that you take in order mostly, or do you mostly skip around within the List (with exceptions of course)?

I would like to hear from somebody from a theater background and conventional console experience, who has now found that multiple Lists are simplifying their lives. 

B 

B Smith,

I have used multiple cue list several different ways in the past. Usually I am trying to get a group of lights to do one thing, but I want the rest of my rig to continue running through normal cues.

I had a show with a lighthouse on the stage, and a moving light was mounted inside to create the lighthouse effect. I needed the ML to sequence through several cues to create the illusion that it was rotating 360 degrees, even though the light was physically not able to do this. My cues were basically:

1. Start pan from SL to SR in 12 sec.
2. Fade Intensity "in" 3 sec
3. Wait 6 sec. and fade  intesity "out" in 3 sec.
4. Pan fixture back to SL in 2 sec
5. loop back to step 1

During the same time the above was happening, I had several cues that were running. There was a sunset on the Syc, an actor entered, and started giving lines, etc, etc... The easiest way for me to do this was to use a second cue list to run the lighthouse effect. I cued the start of the List 2 from List 1. This way the oporator was only using a single "go" button.

Hope this helps a little.

Brent,

Multiple cue lists for me achieve a few different things:

Firstly, different cue lists for different shows -if you're running shows in Rep, you can load the appropriate cue list to the master playback, run the show, and not worry about loading seperate files

We run a rig with quite a few moving lights, so we dedicate an entire cue list to the rig check for them.

If you need to busk an effect, the only way (prior to 1.5 - at least as I understand it) is to have it running in a seperate cue list and pressing "go" on that cue list. In our case, it was some flashing "Applause" boxes sited on the front of the stage - we just had a loop of cues running the effect there.

And, dredging an example up from the past (on a totally different console), having the lights from a "train" outside passing by (white front lights, effects wheels for windows, red tail lights) while other cues are happening onstage. (I realise this could be done with tracking on the EOS, but think I'd still be tempted to do it by multiple cue lists, as it seperates everything out nicely)

Dave

Hi Brent-

Here's a rather more mundane example of a use for multiple cue lists - the rig check.

I set up a cue list 11 that only contains (probably easiest to use [Record Only] when creating it) my FOH scrolls going to each frame with 25% intensity. I create a list 12 for overhead scrolls, etcetera. I can even set up some lists for movers to various positions, 5K conventional lamps that I don't want to flash to full, cyc floods in an order other than their nomal one, etcetera. I put each of these on an Eos fader, probably set with an I-Master.

There are a few advantages here. For one thing, my scrollers in list 11 are referencing palettes - as a result, all I have to do when I find a frame that is slightly out is adjust it and hit [Update]. This will, by default, update the CP and propegate through my show. Ditto any ML positions or colours.

In addition, if there is a problem (I've lost a bubble in one of my overhead scroll PARs and have to send a spark up to fix it), I can fade that list out and work on a different one. Once all of these lists are at the end, I know I'm done. Time for [Go To Cue][Out] to reset all lists (including my main) to the beginning and to run cue 1 of the show.

This, I think, is all very regular theatre type stuff...my main cue list is for the punters, the others are for me!

-luke-

Hi,

I have been accused of having an overly elaborate rig check- 6 or 7 cues with parts delays and follows, referencing scroller palettes and such which end up linking to the House Open Preset.  I just put them in a range way over the show cues, like 901.  I usually do these in Blind as good execise, maybe I'd learn something if I started putting them on another List.

B

Another example of using multiple cue lists is a multiple-night music event or tour, where I know the music that the band might play, but they'll be changing what they play and the order they play at each performance.

So I make a cuelist for each song they may perform - each song has a host of cues doing various things. Some songs might have only one cue, others might have a hundred.

I also make a few 'safety cues' - cues to use between numbers, cues to use if we have to evacuate etc. Some of these go onto standard submasters, others are used at the end of each cuelist to put the stage into a 'safe' state to swap between numbers - the "MC" look if you will.

When they come to play each night, I (hopefully) get a setlist just before they go onstage, setting out which songs they'll play and in which order.

I then re-arrange my playbacks so they are in the order they've said they will play them in - I make sure I've also got a playback for every song they might play, but I'll put the ones I'm not expecting onto a different page.

As the show progresses, I use each playback in turn.

If the band decides move away from the setlist (eg the crowd are demanding a particular favourite), I just have to switch to a different playback.

An alternatie method is to do it all on the Main Playback, and carry your crib sheet of "Song X: Cue List Y", loading each song's cuelist onto Main Playback as you go. That does have some advantages, such as making it very obvious which cuelist is in charge.

When they come up with a new song, I just make a new cuelist for it.

Obviously this can all be done with one big cuelist, but that method means you've got to rearrange large blocks of cues and could easily miss one, and it also means carrying a crib sheet of "Song X: Goto Cue Y" that needs updating every show as you move things around and add/remove cues from songs as the run progresses and 'extras' are added/taken away.

The concept can be expanded for any production you could describe as having a 'set list' that's likely to change across performances - dance, magic shows, sketch shows, large architectural installations etc...

...different cue lists for different shows -if you're running shows in Rep, you can load the appropriate cue list to the master playback, run the show, and not worry about loading seperate files

To which I would add that this allows resident Lighting Directors and visiting designers to work on any piece (think repertory dance ...) at any time, for whatever time is available for work. If the designers are on top of their game, this is a great leap in efficiency and utilization of expensive stage time.

It does require that any special patch for a cue list (i.e. ballet) be available at a touch. In case this isn't obvious, I'm referring to dropping a lamp that hits a piece of scenery from a repertory wash, or different ganging of a bunch of rep fixtures. Typically this might be done with a macro. Of course the macro has to be updated each season if the dimmer assignments change.