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

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

Quote from Soon5

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.