Blackout

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!

I hate to ask this question, but.... are you sure that the channel that needs to fade out has a move to zero in cue 10?  As long as it does, even if it is still in transition when you execute cue 10, it should stop whatever it is doing and fade out in the downfade time of the cue....  if you wouldn't mind checking??

And if the answer is "of course" can you shoot me your show file and identify the channel in question??

thanks!

a

I think the problem may be that it is not obvious how to record a move to zero in a cue when the previous cue already did a move to zero on the channel. What is the syntax to force a move on a channel that is already supposed to be at the same level?

Here's what I did to duplicate the OPs problem using Eos Offline:

1. 1 @ 5 Enter
2. Record Cue 1 Enter
3. 1 Out Enter
4. Record Cue 2 Enter
5. 1 Out Enter
6. Record Cue 3 Enter
7. Cue 2 Time 10 Enter
8. Cue 3 Time 0 Enter
9. Go To Cue 1 Enter
10. Go
11. --- wait a second for Cue 2 to start --
12. Go
13. -- watch channel 1 continue to fade at Cue 2's rate

Cue 3 does not take control of the channel and bring it to 0 instantly. Setting Cue 3 to an AllFade doesn't help either.

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

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

Ah, that explains it. I (indeed we all here) would have expected that continued fading function to be what happened if you allowed the channel to track. That said, I've never really understood assert.

Cheers muchly Anne!

Dave

Anne Valentino said:

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."

Yes, well... it is very different from Expression (as are many things related to the fade logic :-)  Expression effectively had one cue list pointer (even though it had two playbacks); Eos and Ion have 200 cue list pointers.    Expression is also a state machine, where Eos is a move fade desk.   So, while some of the words are the same, the behavior will be different.  

Thanks!

a