@Enter not removing discrete times.


One of my students has accidentally added discrete times of some kind in their show file but they seem very resistant to removal.  I've tried using the @enter with the channels, with colors and with [Group] [Q] [Time] @ [Enter].  Nothing seems to work It's cues 416 and 416.1 that seem to have this issue.  Any thoughts?Street Scene 2011-12-03 14-28-50.esf3d

  • Hi Scott, the syntax to remove discrete time here would be Group Cue Time Enter (no @ needed).  If there are also discrete delays, you'd need to also perform a Group Cue Delay Enter.  Also keep in mind that if you're in Live you'll need to Update the cue for the changes to be applied and the "+" sign to disappear from the PSD.

  • Thanks for your message Paul!  The "at" was just a product of my sleepy brain.  I did the syntax you mentioned for both time and delay.  I think I found the issue (sort of).  I couldn't remove the discrete times directly from the first cue but if I removed the discrete times from the autofollow cue, then the discrete times from the first cue also disappeared.  I'm guessing the discrete times in the follow cue somehow triggered a longer automark time, though this seems like an odd thing to have happen.

  • ah, that's because of marking, maybe you have automark enabled?

    so automark will make the console do the non-intensity move instruction in the cue before, when the light is still off. so the move instruction that is in cue 2 is already used in cue 1. if the move instruction in cue 2 has a discrete time, then this discrete time is already used in cue 1 (because that discrete time belongs to the move instruction).

    that's the one case where the console shows you a discrete time that isn't actually there. one hint would be in the PSD: if cue 1 and cue 2 both have a + and cue 2 has an M in the M column. in this constellation the + in cue 1 could (but doesn't have to) belong to cue 2.

  • Thanks for the clarification!  Yes, my student is using Automark. Do you know what the reasoning is behind this?  I can't think of a situation in which this is helpful.

  • it actually is the only helpful way Slight smile

    the only way to influence automark timing is discrete times. so that clarifies the need.

    on the other hand (not only in mark situations) you can only have discrete times where there's a move instruction. e.g. if the intensity doesn't change in a cue (i.e. there is no move instruction) why should you be able to define what timing should be used. nothing is changing after all so it's useless to say which time should be used for leaving the intensity exactly as it is.

    and the last step to understanding this is: in the dark cue (in my previous example that would be cue 1) the non-intensity parameters don't have a move instruction recorded. the thing that happens while dark (the marking) isn't a move instruction in itself, it is executing a move instruction earlier than it was recorded (in cue 1 despite it actually lives in cue 2).

  • Hi Scott, glad you got it worked out and Ueli has covered the technical reasons it is this way (and it's also this way with manual marking... not just automark).  And while it is actually a useful & necessary function, it is absolutely *not* intuitive.  Sorry it tripped you and your student up!