Multiple cue lists and macros

Following up with things I have learned in case it might prove useful to others, or aid ETC Support in confirming this is expected behaviour.

Hans helped me reframe the question and I was able to get this to work, mostly, by using "Assert 0" to force control back to the master cue list, which is running on the master fader. I say "mostly", because there seems to be inconsistent behaviour when this is done via macro. Foreground macros don't work with the syntax I am using, and background macros don't always execute the Go To Cue, or perhaps they do, but not necessarily on the the asserted cue list, which might be timing related. Where the Go To Cue is particularly an issue is when an ML is part of the cue. It is not coming back to the main cue list unless the the Go To Cue command is entered manually. Is that a User 0 versus User 1 issue?

2012 10 30 10:08:08 Context Cue 91 4

<snip>

2012 10 30 10:08:32 Eos Consol Firing Macro 88
2012 10 30 10:08:32 Key_Event U:0: Live CLEAR_CMDLINE
2012 10 30 10:08:32 Key_Event U:0: CLEAR_CMDLINE
2012 10 30 10:08:32 Context (L)USER: 0-> Live
2012 10 30 10:08:32 Context Cue 1 2 
time: 330 10:08:32 Context Go 33
time: 030 10:08:33 Context Off 33
2012 10 30 10:08:34 Key_Event U:0: Assert 0

So then I tried using the fader Off command which might produce better results, but I won't know until I try it with the live rig.

2012 10 30 10:08:40 Key_Event U:1: MacroButton
2012 10 30 10:08:41 Key_Event U:1: 3
2012 10 30 10:08:41 Key_Event U:1: 3
2012 10 30 10:08:41 Key_Event U:1:
2012 10 30 10:08:41 Eos Consol Firing Macro 33
2012 10 30 10:08:41 Key_Event U:0: Live CLEAR_CMDLINE
2012 10 30 10:08:41 Key_Event U:0: CLEAR_CMDLINE
2012 10 30 10:08:41 Context (L)USER: 0-> Live
2012 10 30 10:08:41 Context Cue 1 3
time: 330 10:08:41 Context Go 33
2012 10 30 10:08:42 Key_Event U:0: Assert 0 Go_To_Cue Time 0

... and yet more feedback on my ongoing struggles with what ought to be really simple but isn't (see the first post for the scenario)

Macro (background mode) is:

Go 32 Macro_Wait 1 Assert 0 Macro_Wait Go_To_Cue Time 0 *

which is supposed to execute cuelist 32 (looping 2 step cue), wait for it to finish, assert the main cue list and then force that cue to bring back any channels that might have been grabbed by 32.

The Go_To_Cue doesn't consistently work when fired from a macro but always work when executed manually. So the macro has been modified to mostly run in the background but fire the Go_To_Cue in the foreground by calling another macro for that task:

Go 32 Macro_Wait 1 Assert 0 Macro_Button 40 *

Macro 40 (foreground) contains:

Go_To_Cue Time 0 * 

This convoluted approach seems to be yielding more consistent results but I won't know until the run-through tonight. Maybe the Assert should be a Fader_Assert and also run in the foreground, but I don't have time to experiment.

I think things would be a whole lot simpler if there was a Macro mode called do-what-it-would-have-done-if-somebody-physically-pushed-the-button.

sk8rs_dad said:

I think things would be a whole lot simpler if there was a Macro mode called do-what-it-would-have-done-if-somebody-physically-pushed-the-button.

And I always thought, that is what the learn button does. Or is it not.....

Have you tried using learn?

Florian is correct.  You should be able to write a macro for your secondary cue list of [Release] + [Load].

??

a

As this long chain will attest, I agree that I should be able to write a macro, but the macros do not behave as expected. I have spent about 10 hours getting to this point and shown all my work but it doesn't work as expected, and I get different behaviours when it is a foreground or background macro. So the question remains, what should I be doing.

Thanks.

/Karl

... and yes I started with "Learn" and it did not work without having to add Go To Cues and even then it didn't work because the Go To Cue wouldn't take in a background macro.

OK.  One step at a time.

Just to be clear.  You are simply trying to write a macro that releases a secondary cue list to the last cue list that had control of specific lights - which in your case is your master list?  I'm not clear on why you were asked to use an assert command or go to cue - one of the developers and I discussed this and unless we are completely missing something, we are confused by that.  But I've put in a call to Hans.  Perhaps he can help clarify. 

Please assure that you have not set a background disable flag on your master cue list.

Put yourself into some cue in the master list that involves these lights.

Manually playback your secondary list.

Can you use the release command on your secondary list manually and return control to the master?   (That would be Release and Load).  The release command will leave the secondary cue list where it is.  If you want to release and also set the secondary list to the top of the que, use Off and Load.

If you can do it manually, can you learn a macro 

learn macro n enter [Off or Release] and Load. Learn

Rerun the cues as before and manually run the macro?  Does it work?

If that works, how are you triggering the macro in your show.

I just tried this, and unless I'm missing something that you are trying to do, it works fine.  

If it isn't working, please email me your showfile (anne.valentino@etcconnect.com)

Thanks so much.  We will sort out what is going on.

a

Thanks Anne. I have always figured it is something I am screwing up but I had to blaze ahead with limited knowledge because we open on Sunday and a half-baked answer is better than no answer at all. I will give your recommendation a shot when I am back in the theatre this evening. I thought I had already tried it but maybe I messed up a keystroke somewhere.

No problem at all.   Very interested to hear what you find.

Thanks much!

a

 release and load brings back the intensity in the primary cue list  but the color parameter and possibly other np parameters are not restored  to where they were in the primary cue list.  they track in from an ealier cue.  i will send the showfile after rehearsal since i don't have internet access  

Ok.  Will need to know the cue on the primary you are restoring to and the cue on the secondary you are restoring from - and the channels.

Thanks much!

a

I think I have figured out what is happening, and I think its a bug.

Try this scenario:

• Create a default preset and set the color temperature of some D40s to 5000.
• Create a master cue list that has color temperature as null throughout.
• Create a second cue list that sets color temperature to 2000 -- don't ask me why or how... it's been a long week :)
• When the secondary cue list fader releases to the main fader the color temperature does not come back to the default.

I didn't get a chance to confirm my suspicion before I had to leave the theatre to run an errand but based on what I was seeing it would explain the red-shifted splotches on certain areas of the cyc that had been part of the secondary cue list.

Plausible?

Nope.... not a bug.  If you have nulled the parameter in the master, when you release to the master, the color temp is not getting a new instruction - so it stays where it is (nothing moves unless you tell it to move).  If you want it to home when you return to the master, you need to have the home values stored into (either as moves or tracks) your master list.   The general rule for NPs is that we don't move them unless you give us an instruction to move them. 

Hope that helps.

a

Nope.... not a bug.  If you have nulled the parameter in the master, when you release to the master, the color temp is not getting a new instruction - so it stays where it is (nothing moves unless you tell it to move).  If you want it to home when you return to the master, you need to have the home values stored into (either as moves or tracks) your master list.   The general rule for NPs is that we don't move them unless you give us an instruction to move them. 

Hope that helps.

a

I think we're going to have to agree to disagree on that.

If the NP value in the master cue list is coming from the default Preset prior to executing something on another fader, it should return to the default Preset upon releasing that fader. That is, the default Preset should act as though it tracked in from Cue 0. Otherwise, Release, Off, and Assert 0 won't actually do what they allege to do which is return the rig to whatever look was active before the event that changed it. Is the workaround to record the default preset into the first cue in every list and force it to track through?

You need to have an instruction for those lights in the master cue list if you want them to return to it.   So you can go to the first cue in the master list and add the necessary parameters at their home value.

Thanks much!

a

sk8rs_dad said:

If the NP value in the master cue list is coming from the default Preset prior to executing something on another fader, it should return to the default Preset upon releasing that fader.

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

sk8rs_dad said:

Is the workaround to record the default preset into the first cue in every list and force it to track through?

I wouldn't call this a work around, it's actually how this should function, but yes it will give your main list a background level to be restored to.

Cheers

Dan

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.

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.

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