Delay timing

G'day

From what I can gather, the delays work in the same fashion as timings.  With timings, if the up and down fade are the same (not split, and there is only one box in the intens time column) then changing the time will change both up and down times.  Once you have a split time (and there are 2 boxes with values in the intens column) then you have to use the [time x time y] syntax.

From what I can gather, Delays work in a similar manner.  If you apply a delay to a cue, it will delay both the up and down times, even if you have a split timing on the cue.  Therefore on a cue with a time of 2/4, [cue n time 3] will delay both the up and down fade by 3 seconds.  If you only wanted to delay the up time, then you would enter [cue n delay 3 delay 0].  This will add a delay to the upfade only.

Once you have different delays on the up and down times, then the syntax [cue n delay 2] will only alter the up delay.

I must say, it would be nice if you could use the syntax [cue n delay x delay enter] to only change the upfade delay if the cue does not have a split delay time.....

Cheers 

Of course! [Delay][x][Delay][0] didn't really occur to me for some reason, I was going down the approach you suggested Brent, being [Delay][x][Delay][Enter] to give the down no delay at all. Don't see why that syntax couldn't be an option....?

Thanks

[Command][Enter] is used in other places to remove/clear/unset a previously set attribute rather than assign a value of [0]. For instance, [Park][Enter] un-parks a parked channel.  Semantically there can be a big difference between [0] and NULL and ETC seems to be exploiting the difference.

Alternatively, ETC may be trying to be nice about preserving whatever value was already stored by requiring a new value to be explicitly entered rather than assuming you meant to enter [0].

On consoles I have used in the past, to do a split delay and preserve the timing on, lets say, the up delay, the syntax would be [cue n delay x/].  To preserve the up delay would be [cue n delay /x].  My 2c - it would be nice to have something like that.  Then again, maybe it's just something I'll get use to over time (which is very possible!)  :-)

cheers 

Call the question....

I much prefer [time] {x}/{y} to [time] X [time] Y

Technically the same number of keystrokes, but for some reason I find the slash speeds me up
 

I agree - much prefer x/y syntax.  I'm quite sure i read somewhere this will be possible in one of the software releases soon (yay)
 

Hey guys,

I for one had been rueing the loss of the x/y syntax at first, but now I think I've become happy with Time and Delay keys.  I think that if the option were to become available now, I probably wouldn't switch back.  While it is the same number of keystrokes, it adds a different key in a different area of the keyboard- not very cumbersome, but just enough to be less efficient for me.

I'm not trying to discourage this idea, but think about this- if you wanted to affect the color timing only would you propose [Time / / X]?  Would you want the command line to display which timing is being affected as you add more slashes? ("Is Focus three slashes or four?")  Sometimes, I press the Time key too many times and pass, say, Color.  I know that if I keep pressing that same key, in a max of four presses It'll come back around.  Do you think that on the fifth slash, the command line would clear back to uptime?

Just food for thought, B

I personally would prefer it if each press of [time] cycled through IFCB time. ie: first press = intens time, 2nd = Focus 3rd = Colour, 4th = Beam, with the slash key being used to specify split up/down fade times and delays.. Just my 2c

CHeers 

I personally would prefer it if each press of [time] cycled through IFCB time. ie: first press = intens time, 2nd = Focus 3rd = Colour, 4th = Beam, with the slash key being used to specify split up/down fade times and delays.. Just my 2c

CHeers 

Thanks for all of the commentary on this all.  Look for it in 1.5....

a