Why does the first Go on a cue list include an Assert?

I hate when I have manual data that gets lost when pressing Go on a cue list. I want to be able to have a Cue list in my show that has no effect at all on anything other than a specific channel. Is this even possible?

Thanks!

  • If you want your manual values to stay, you can always capture them.

  • Of course, but that’s needed every time. Sometimes I just have a 2 Cue Cuelist that turns haze on, or an NDI stresm into Hippo. Should I have to Capture a whole look everytime someone needs to turn on haze?

    I wonder why the Assert is there in the first place.

    I’d say, let the user manually Assert if needed and have all Cue List stay out of the way of manual data - unless there’s a move instruction of course.

  • I think you'll need to share a show file / screenshot of your cues to get the most helpful answers. Something isn't quite lining up. I think I'll try to redirect this thread in a different way...

    What is you're wanting to accomplish? By my notes so far you're wanting to make a cue list to execute certain parameters of channels and not make any other data changes? That's fairly basic programming, but I'm more curious to discover if it's the best/easiest way to accomplish your goal.

    Also what console are we looking at here? What magic sheet / macro buttons/ faders do you have available to you?

  • this will not make a difference in your situation right now, but it's still important to note: it's not the first cue that has an assert.

    you're using probably Go From Last = Wrap? this is an out-of-sequence command which (like all other OOS commands) triggers the assert behavior.

    some other examples are:

    GoToCue
    Back
    Link

    instead of Go From Last try using
    Cue <last cue> Link <first cue> Loop 0 Enter

  • So the answer I got from the question of “Why do my manual intensity values go to 0 when pressing Go on a cuelist?” was basically that when pressing Go on the first Cue in a List, it will always include an Assert.

    I don’t ask for anything other than to leave manual data as is, when executing Cues that aren’t affecting the manual data. So that when I’m creating a look, a list with something utility related like haze for example (or anything else for that matter) will not force all manual intensity data to 0%. 

    Basically I want my other Cue Lists to stay out of my way. Don’t affect data that doesn’t belong to you.

    As for console, I have an Eos Ti. 

  • Curent settings do indeed turn my manual intensities to 0%.

    edit: …only in the first cue.

  • Just as John sayed, right know there are only a few option to avoid the override.

    - Capture your manual values (there are 3 ways of capture)

    1. keep them selected in your commandline. Also known as commandline-Capture
    2. <selection> [Capture] [Enter]. will place a yellow C on your capured channel/parameter
    3. [Capture][Capture][Enter] (this will post 'Capture Enable' to you commandline). This will make every Manual value automaticaly a captured Value, from now on, and will have also a yellow C on every channel/paramter

    - use a Submaster (as you say haze is one of your main feature, go make a Submaster out of it)

    - make a quick save of all your manual data in a place-holder-Cue-List (maybe with a macro). I think something like that was shown in the advanced FX-Tutorial.

    - maybe something else i could not think of right now...

    -----

    I feel with you. But right know there is nothing more than to work around or prevent to have manual data.

    You can make a feature request. And maybe it will make it into a new EOS version somehow.

  • Thanks Mathilda. I'll probably do some macros with one of the methods you suggested for now.

    Just to mention, the haze example is just for simplification. I also have cue lists running other important stuff all the time. The reason I mentioned haze is that I have usually just used a submaster for haze and smoke machines and such, until one day I wanted to have a very specific pattern of smoke-blowing in a show. So I made some cues in a list. This sequence could be triggered at any time by sound. You can probably figure out what would then happen when I was trying to work at the same time. 

    Now I'm running into the same thing when using a list as kind of an effect - a 3 cue list that gets repeated and every third Go it will take away everything I'm working on. 

    There must be something I'm missing, this can't be it - is it? I can't see how other programmers haven't run into these scenarios before.

  • If you are working on something and will record it in something in the near Future, use the "Auto Capture" function. Or if you not want to record it and just like to have it up for some while... I would recommand that.

    [Capture][Capture][Enter] (this will post 'Capture Enable' to you commandline). This will make every Manual value automaticaly a captured Value, from now on, and will have also a yellow C on every channel/paramter
  • Sorry, I know this is an old post, but I have an answer that may help you.

    In the fader config for your cue list, if you do a channel filter for only the channel(s) that are in the cues, then running the cues will not affect any manual data on any other channels.

    (I too have been annoyed with losing manual data on a Go.  I busk movers with manual commands, but have the houselights on a cue list.  My intensities are always on subs, so I didn't know/remember that intensities fade out. With NIPs, they lose manual status and the reference labels disappear, but the parameter values don't change... so the show isn't affected, just my ability to know what that fixture is doing exactly.)

  • Thanks for contributing! Handy tip!

    I am basically asking for an official explanation for why this should be the default behaviour, because it’s very unintuitive and hard to work around. If there’s a good reason for it, then great, maybe I can work it into my workflow - but as of now it’s only causing me a lot of problems due to unexplainable behaviour.

Related