Cue Timing and Go To Crossfade

  • I have a question regarding the Right-click Go To feature and crossfade timing. In the properties of the cuelist I have changed the following:


    Tracking: False

    Use Cue Time as GoTo Time: True


    I created 3 cues with the following settings:


    1. Lights Up Fast [Fade:0ms] - All lights at 70%

    2. Lights Up Fade [Fade:8s] - All lights at 70%

    3. One Center Light Fast [Fade:0ms] - One light at 100%


    1. Use GoTo Cue #1 - All lights jump to 100%.

    2. GoTo Cue #3 - Center light 100% fast and all others blackout fast.

    3. GoTo Cue #2 - All lights fade 8 seconds to 100%.

    4. GoTo Cue #3 - Center light 100% fast and all others 8 seconds to blackout.


    Why is the GoTo timing of cue #3 different? I find this to be odd behavior. I thought by setting tracking to false and using cue time as goto time that the fade time of the cue is what should be used regardless.


    The same is true if you use the traditional GO button. If you hit GO the last cue will take 8 seconds even though it's fade time is set 0ms. I have a sample project if needed.


    Am I missing something?

    Rico

  • yes, please provide the project.


    My assumption is it works if you set Tracking to true and explicitly set the other lights to 0% in Cue 3.


    Not having looked into the code my assumption is that due to not having a "fade out" time for the Cue 2 Values, the Fade In Time is reused.

  • Yes you are correct. If you explicitly go to every light in your project and zero out all settings then yes, the lights work, but that's not right. The whole purpose of setting tracking to false is so that the cue is the only information sent. And how do you explain why the cue drops the lights instantly when coming from a zero fade time, but if your last cue has a long fade time, your lights will take that long to go to zero. This is actually overwriting the fade time of the cue. But if you have the "Go To" time set to the cue time, then the cue time is suppose to have priority. At least that's how I understand it. The current behavior does not make sense.

  • It's easy. You just have to set the "Tf" Flag in the Target Cue.


    This Flag means "Take Fades" which actually indicates that this cues Fade / Delay Timings overwrite the "Source" Fade / Delay Timings.


    The Behaviour makes sence because this way you can decide whether you want to apply the Target Cues Timings or the Source Cue Timings.

  • Maybe a little bit more explanation on this behaviour and the difference in Tracking / Non Tracking.


    In Tracking Mode, each cue fades in new Values with the Fade time defined in that cue. So the existing values are overwritten by the new ones, new ones are added. Untouched Values stay as they are.

    In Non Tracking Mode two things happen.

    1. New Values are added / overwritten similiar to "Tracking" Mode, so here also the new cues fade times apply.

    2. Old Values which don't exist in the target cue need to be faded out. Here per Default the values are simply rolled back with the same fade value that originally wrote them. This is the reason why in your case there is a difference when you jump from 1 => 3 vs. 2 => 3. To enforce using the same fade / delay timings as the Target Cue, the "Tf" Flag is used.


    Hopefully this helps.


    Regards


    Arne

  • Thank you for explaining the Tf flag and how it works in conjunction with tracking.

    Here per Default the values are simply rolled back with the same fade value that originally wrote them.

    Why over complicates things with another flag? I get why it is there, but why not simply follow the in/out fade times of the cue when tracking is turned off? This way you wouldn't experience the unpredictable behavior I did. Without the Tf flag checked you are at the mercy of the last cue executed making your cue transitions unpredictable in live shows. From my perspective it seems like an unnecessary flag or at least the default should be checked.


    I searched everywhere for an explanation of the Tf flag. I eventually found a post you made in 2016, but at that time you didn't understand how the Tf flag worked. The documentation shows a "Re" tag here rather than the "Tf" flag that's there now. I've been trying to research the wiki pages and this forum before requesting help. Hopefully this post will help others understand this better.


    I will set the Tf flag to true as a default to insure the cue being executed follows the fade times of the cue.

  • From my perspective it seems like an unnecessary flag

    What's unnecessary from your perspective is required for others. The Flag is not there without a reason it's because we had other cases where users requested it. That's why the flag is existing.

    the default should be checked

    You are free to configure all the Defaults for all of the Flags on a Cuelist, Project and Application level, so it's up to you to just do it.