Multiple cue lists and macros

What is the opposite of an Assert and how does one go about recording it into a macro?

The sound guy is triggering a variety of flashes via MSC by firing a set of macros to simulate flashes of explosions using various lighting instruments that are also being controlled by the master cue list. I want him to be able to grab control, execute a secondary cue list, then release control back to the master cue list, with those lights returning to the state they are supposed to be at in the master cue list.

According to the training videos and documents this is supposed to be possible by running the secondary cue list on a fader and then using {Off} to release the levels back to the master play list. I can't make this work and I don't know what I am doing wrong. Does anybody have a sample macro I could use as a template?

  • dsmurfin said:
    The entire principle of a move fade / tracking console is that nothing will ever move unless it is given a move instruction. Those default presets are not background levels unless they are specifically reference in a cue or sub etc. They are null values (gray).

    That's sort of my point. If they have never been set and they get set somewhere then they are staying set instead of homing again. The current implementation forces me to record the home value into any and all targets and if I am not using all the lights in the house rep plot I have to record a value anyway just in case I might use it, which makes Flexi Patch and Flexi Show redundant for those fixtures. I'm not sure what the impact of that is going to be on soft blocks popping up while mucking about with cues. I guess Record Only becomes your closest friend.

  • Quick question. I had a similar problem recently. Technically, couldn't you just "Assert" the cue that is executed when releasing the second cue list? Wouldn't that treat every NP value in the console as home, if nothing was previously programmed in?

  • Unknown said:
    Technically, couldn't you just "Assert" the cue that is executed when releasing the second cue list?

    The asserted cue list would still have no values for the channel in question, so it would have nothing to assert it too. The principal is you have to have actually have some value in a cue list be that in the cue in question or tracked from a previous cue. This the way any true mode fade desk should work.

    Cheers

    Dan

  • dsmurfin said:

    The asserted cue list would still have no values for the channel in question, so it would have nothing to assert it too. 

    Okay, But if your home position is also being tracked from the beginning of the show, then Asserting that returning cue should in theory bring it back to the main list right? I guess you would also have to Block it as well.

    Where I'm running into trouble understanding is, if a move instruction is needed but the instruction I want to give isn't a move instruction.... what do I do?

    For example. The home value for a strobe on a Mac250 is 35. That equals no strobe. That value is in my preset that is my home position. If I don't use the strobe anywhere in cue list 1, but I do in cue list 2, when I try and bring control back to cue list 1 how can I give it a move instruction? Because, in Cue list 1 there are no move instructions for the strobe attribute. It stays at 35 the whole cue list.... so when I execute Cue list 2 and the strobe is at 220, how do I release cue list 2/ during playback so that it returns to a value of 35 (which is a tracked value as far as cue list 1 is concerned).

    I thought that [Assert] would do the trick, but as you said, it has nothing to assert to. How do I force the cue and the "Home" values to assert themselves?

    Hope that makes sense.

    Thanks,

    CBJ

  • uhm, as long as you have no value, there's nothing to assert, right. but when you say tracked value, that means at some point there was a move instruction. so if your strobe channel never gets a value in cue list 1, then assert won't work. but if you give it a move instruction in the first cue of cuelist one and then track that, there's a value to return back to. and even if this move instruction is the home value of the channel.

    or did i let myself get confused?

    ueli

  • Which brings me back to my assertion (pun intended) that home preset values should be treated as though they are move instructions that tracked in from cue 0, or there should be a big red warning to the unwary and uninitiated that they are about to learn a painful lesson about working with default presets and multiple cue lists.



    [edited by: sk8rs_dad at 2:20 PM (GMT -6) on Thu, Nov 22 2012]
  • Ok...

    Ueli, that is exactly right.

    CBJ. The issue that was originally mentioned in this conversation was a situation like that. The home preset in setup does not mean you have a background value, that has to come from a cue or submaster etc. If you want something to act as a background level for something else it actually has to have a move instruction for that channel which is either a hard value in that cue/sub or a tracked value.

    I hope that clarifies things a bit.

    Cheers

    Dan

  • sk8rs_dad said:

    Which brings me back to my assertion (pun intended) that home preset values should be treated as though they are move instructions that tracked in from cue 0, or there should be a big red warning to the unwary and uninitiated that they are about to learn a painful lesson about working with default presets and multiple cue lists.

    Except you don't want that to act as a background. There are instances where it is desirable to release a cue list and things stay where they are. If you always count the home preset as a background value you seriously break that. The essence is if you want something to have a move instruction you need to give it a move instruction.

    Happy Thanksgiving!

    Dan

     

  • That makes perfect sense now.....

    What I did (and the mistake I made) was assumed that because I created a home preset that those values were active in the cues, but I get it now.... those values were never tracked because they were never used in the first place, so there was nothing to assert to.

    Ha!

    Okay, that seems like a mistake EOS programming wise... just because when an intensity value has nothing, it displays nothing..... where as when NP have no value, they show the home position.... this difference leads me to believe that there's a value there, even though it's greyed out.

    Maybe this just became a suggestion, eiher have nothing in the NP boxes if no value is there (even though it's pushing out a home value) or for NP use those home values as absolute values that track in from cue 0. That way they always have a hard value in the cue list, since in real life they always have a value.

    My 2 cents...

  • Dan,

    First Happy Thanksgiving!

    dsmurfin said:

    Except you don't want that to act as a background. There are instances where it is desirable to release a cue list and things stay where they are. If you always count the home preset as a background value you seriously break that. The essence is if you want something to have a move instruction you need to give it a move instruction.

    Second, correct me if I'm wrong but if you don't [Assert] the returning cue, you get the behavior that you discussed. The NP will stay were they are from the 2nd cue list, if they don't get move instructions. So really, unless I'm understanding it wrong, even if the board did treat Home values as Move Instructions in Q0 (which would solve the problems sk8rs_dad and myself were having) all you would have to do to keep the lights in the cue list 2 state is NOT assert them. Right?

    sk8rs_dad said:

    Which brings me back to my assertion (pun intended) that home preset values should be treated as though they are move instructions that tracked in from cue 0, or there should be a big red warning to the unwary and uninitiated that they are about to learn a painful lesson about working with default presets and multiple cue lists.

    sk8rs_dad, i wholeheartedly agree. However, I guess it comes down to a matter of philosophy.
    With Intensity, if there's no move instruction there's nothing in the box. If there is a move instruction (even to zero) it displays a number.
    With NP, even if there are no move instructions, it still displays a number so a newcomer is tricked into thinking there's an actual tracked value there when there is not.
    I'll know better for next time, but it seems counter intuitive as it stands currently. Whereas a lights intensity is either used or not used, a moving lights attributes are always used, that's why we (or ETC in most cases) took the time to make a home preset. So in it's default state it does what we expect.
    So shouldn't that default state for NPs be asserted at the top of a cue list? (without having to do it ourselves as I will do from now on).

  • Unknown said:
    Second, correct me if I'm wrong but if you don't [Assert] the returning cue, you get the behavior that you discussed. The NP will stay were they are from the 2nd cue list, if they don't get move instructions. So really, unless I'm understanding it wrong, even if the board did treat Home values as Move Instructions in Q0 (which would solve the problems sk8rs_dad and myself were having) all you would have to do to keep the lights in the cue list 2 state is NOT assert them. Right?

    Hi Carl, that's not quite right. If I have a background level and I release a cue list acting on the same channels the levels will return to the background level. I'm not asserting or not asserting anything here, I'm just releasing another source. I don't think you've quite understood how assert works. This example might help...

    Example 1.

    Home Preset:  Chan 1 Pan @ 20

    Cue list 1/1: Chan 1 Pan @ 50

    Cue list 2/1: Chan 1 Pan @ 100

    From a go to cue out state, run cue 1/1, then run 1/2. Channel 1 will have Pan @ 100

    Release + Load cue list 2/1, channel 1 Pan goes to 50.

    Release + Load cue list 1/1 channel 1 Pan stays at 50. (if that was a background pan would have changed to 20, not what is desired).

    Chan 1 Sneak, channel 1 Pan goes to 20.

    Notice I haven't asserted or not asserted anything here. That's not relevant in this scenario.

     

    Example 2.

    Again, from a go to cue out state. Run cue 1/2, then run cue 2/1, channel 1 Pan goes to 100

    Assert + Load Cue 1/2, channel 1 pan goes to 50.

    Release + Load Cue 2/1, channel 1 pan goes to 100.

    This is the purpose of Assert, when it is used it forces that source to take the channels with it. I can't do that in example 1 as I'm not actually doing anything, just releasing a source.

     

    I'm afraid to say guys this is a fundamental concept of a move fade system. Hopefully this will clarify things a bit.

    Cheers

    Dan

Related