A Sneak Delay thought

Yeah this seems like an issue.

• (1) @ Full in Cue 1
• (1) Full Manually
• (1) @ Out in Cue 2, with a 30 second time
• Take Cue 2 with (1) still selected and manual at Full
• (1) Sneak 5 Delay 5
• (1) waits 5 seconds, and then fades over 5 seconds to whatever (1)'s background value was mid-fade, then snaps to the current point in the fade and continues in remaining cue time

I think ideally when sneaking to the background value, the target background state should be re-evaluated per-frame. IE (1) should catch up to the current position in the fade from cue 1 to 2 over 5 seconds, and then continue smoothly from there in cue 2 time.

This issue isn't related to delay though, if I repeat the above example using just sneak:

• (1) @ Full in Cue 1
• (1) Full Manually
• (1) @ Out in Cue 2, with a 30 second time
• Take Cue 2 with (1) still selected and manual at Full
• (1) Sneak 5
• (1) starts fading over 5 seconds to whatever (1)'s background value was mid-fade when I pressed enter, then snaps to the current point in the fade and continues in remaining cue time

This is tricky because it either involves whatever powers sneak to anticipate what the end state will be of the fade and plot an intercept to that over a given time, which will break in the same way as it currently does if you then take another cue and change the fade target. Or you can get a non-linear sneak fade as it accelerates to catch up to the background state. I think either is preferable to the current implementation, but a non-linear and no-jump sneak is the preferable outcome.

Yeah this seems like an issue.

• (1) @ Full in Cue 1
• (1) Full Manually
• (1) @ Out in Cue 2, with a 30 second time
• Take Cue 2 with (1) still selected and manual at Full
• (1) Sneak 5 Delay 5
• (1) waits 5 seconds, and then fades over 5 seconds to whatever (1)'s background value was mid-fade, then snaps to the current point in the fade and continues in remaining cue time

I think ideally when sneaking to the background value, the target background state should be re-evaluated per-frame. IE (1) should catch up to the current position in the fade from cue 1 to 2 over 5 seconds, and then continue smoothly from there in cue 2 time.

This issue isn't related to delay though, if I repeat the above example using just sneak:

• (1) @ Full in Cue 1
• (1) Full Manually
• (1) @ Out in Cue 2, with a 30 second time
• Take Cue 2 with (1) still selected and manual at Full
• (1) Sneak 5
• (1) starts fading over 5 seconds to whatever (1)'s background value was mid-fade when I pressed enter, then snaps to the current point in the fade and continues in remaining cue time

This is tricky because it either involves whatever powers sneak to anticipate what the end state will be of the fade and plot an intercept to that over a given time, which will break in the same way as it currently does if you then take another cue and change the fade target. Or you can get a non-linear sneak fade as it accelerates to catch up to the background state. I think either is preferable to the current implementation, but a non-linear and no-jump sneak is the preferable outcome.

Ahh yes, I see it happening without delay as well. Never noticed until now. Your suggestion about a non-linear approach seems the most reasonable to me, as it would allow an op to run cues while a sneak is running and be confident that no jumps in the fade engine will happen. An unintended jump really is horrible to experience.

Let’s see if anyone from ETC chimes in.

Regarding your second example, I have actually never had a problem with channels snapping when running cues and sneaking. Not at a desk so I can’t test, but do they not sneak and line up with the cue fade linearly? So in a sense, anticipating where they’ll be in x many seconds, given you don’t go the next cue?

I might be mistaken, but I sneak and Go a LOT, and never had an issue until using Sneak Delay.

I was playing around with it offline, and that's what it appeared to be doing in the tombstones.