Blackout

Question

Hi guys, 
 We're in tech for a show at the moment, and have just come across a rather interesting feature.... 
 
 Cue 9.5 brings one light up, and another out over 35 seconds 
 Cue 10 is a blackout over 1 second 
 
 If cue 9.5 is not complete when cue 10 is run, the light going down continues to fade at the same rate - leaving it up in a blackout! 
 There are several solutions we've found which work: 
 
 Put the channel going down into a part which fades faster 
 Put a quicker out time than the up time 
 Put the channel at 01% in Cue 9.5 (Cue 10 then takes over to take it to black) 
 
 We haven't found a hidden setting yet to alter this behaviour - is there one? 
 
 ETA: We're using V1.4.2 at the moment - so is this just a function of that?

Anne Valentino · Accepted Answer

The basic logic of the desk is to follow move instructions on playback. So, if a light is fading to zero in a cue, and you execute a new cue, with new timing, where that light has a tracked value, the light will continue fading in its original move time. Just to be clear: 
 Channel 1 at full in cue 1. 
 Channel 1 moves to zero in cue 2, in 10 counts. 
 Channel 1 is stored with a tracked zero in cue 3 - and lets say thats a bump cue. 
 If you execute cue 3 while cue 2 is still fading, because there is not a move instruction for channel 1 in cue 3, (it has a tracked instruction) it will continue fading in the timing from cue 2. To force a move for channel 1 in cue 3, you can place an assert flag. This flag can either be on the entire cue, on a cue part, a channel or a channel parameter. [Cue] [3] [Assert] [Enter] - will assert all of the tracked values in cue 3. To place the assert just on channel 1, from live, while you are in cue 3, [1] [assert] [enter] ... make sure to update or rerecord. You can place the flag on a channel level in blind and have it automatically store. 
 When a channel (or channel parameter) has been asserted, the value will still be in magenta, but you'll see a blue 'a' in superscript to the right (and you'll also see a lower case "a' in the assert flag field of the cue in the cue list. If the entire cue or cue part is asserted, you'll see a capital A in that field. 
 Assert is a way to take tracked values, allow them to continue to be edited like tracked values, but treat them like move instructions on playback. 
 It is related to (but different from) blocking. When you block a cue, cue part, channel or channel parameter, you a treating the blocked element like a move instruction from an editing standpoint, but it continues to act like a tracked value on playback. 
 One more bit - you can also assert an entire cue list, which effectively puts a move instruction (from a playback standpoint) on every parameter stored that cue list. You can do this in the cue list index. Double hit the Cue button. Select your cue list and place the assert flag [Cue] [1] [/] [Assert] [Enter] 
 So, block is an editing function, assert is the corresponding playback function. Does that make sense? 
 Allfade does not affect channels in the cue that has the allfade flag.. Allfade affects channels that are coming from other cue lists. So, when you place an allfade flag on a cue, you are essentially saying "If you are not getting your intensity from this cue list, you should fade out." 
 Hope that helps! 
 a

Brian Webber · Answer

You can put individual fade times on a channel without it being a part cue. If you go into the cue that you want the light to go down in, and say chan [x] time [y] enter. Then record, enter and it will then have a letter (cant remember the letter) next to that channel which tells you it has its very own fade time. 
 I would say the "problem" you are describing is actually a feature. If it were the express, it would do what you want it to, but on these consoles, it will actually complete the fade first (I think!). 
 Good luck!