• State Not Answered
  • Date
    Palmi Jonsson
  • Date
  • Replies 4 replies
  • Subscribers 188 subscribers
  • Views 505 views
  • Users 0 members are here

A Sneak Delay thought

If I have channels fading from 100% down to 0% in 60 seconds and I do a Sneak Delay 30 halfway through, should the channels sneak to 50% or 0%? I had this scenario come up recently and I am quite sure in that case it was going to sneak to 50% even though the cue fade had run before the delay time was up. I wonder if when removing manual data with sneak, it should wait for the delay time until it determines the background values.

This particular case caused my channels to fade up to the % the background value is at the time of sneak execution, in sneak time, after the cue had completed (where the channels were fading down to 0%). And as soon as the channels hit that value, they snap to 0%, causing a jarring behaviour. I assume this gets increasingly weirder once params other than intensity are used.

Love the feature though, just a little quirk!

Parents
  • 0

    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.

  • 0 in reply to Taylor C Jensen

    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.

Reply Children
No Data
Related

www.etcconnect.com