Feature request: Release Cuelist after last cue

Something along these lines is due in 2.4, hopefully.

Hi

You can make a macro to release the cue list . "playbackrelease 3 enter" which you can make with [learn][marco][x] [release][load].
This you put in your last empty cue.
Only thing is that there is some timing which I can't get to O sec.
So when there is a fade that you can't control to the home status of the parameters that change because of other cue's ore sub's that take over.

Yeah that's my current workaround for the issue. Except that every time you move the cue list to a different fader and the playback # changes, you have to update the macro.

When you get into multiple list it's much better to manage the playback number in the fader config.

I make the playback number the same as the cuelist number. So map a fader as playback 10 in the fader config and then back in Live map cuelist 10 to that playback. That means my macro's never break.

Release should be using the Assert time, so changing that in setup should give you a 0 time.

Having said all this, this will all change for the better in 2.4 which is currently in development.

Hi Nick

I tried changing the Asserttime to 0 but tha did not change take out the fade time on the non intesity parapeters when using the macro [playbackrelease X enter} in a cue.

Marnix

Hello Nick

When I have a cue 1.1 running with a effect [X} and I start cue list 2.1 with Effect [X]. Than I playbackrelease Cuelist 2 with a macro[n] Cuelist 1 takes over again but without Effect [X]. The Effect is stil there in the list but the channel numbers are grey.
Is there a way to make the Effect run again?

Marnix

The only way to start this again is to Assert the playback running list 1. Playback Assert+Load button or if you have cuelist 1 on the command line, hardkey Assert Enter.

Hopefully the developers (well Dan Duffy) can fix this in 2.4.

"So when there is a fade that you can't control to the home status of the parameters that change because of other cue's ore sub's that take over."  - Exactly why the EOS concept of LTP is flawed.  No other playback should assert itself until told to do so.

Or at least allow that behavior as a toggle state.

Can you explain further please?
thanks,
a

Hi Anne
I have seen that in 2.4 Alfa you got the possibility to set a time to release in the setup. so this way you have to make complecated macro for every cue list you want to release. I rather would like to be able to set the time direct to relaese in a macro.
I think what SBC is saying that. When using a new cue list 2/x with an effect. The effect that was running on the background cue 1/x has been asserted. And when the second cyelist is released the old effect is not working any more. But in fact the background cue 1/x that you want to take over again should be working as a LTP and start working again.
Marnix

Hi Anne
I have seen that in 2.4 Alfa you got the possibility to set a time to release in the setup. so this way you have to make complecated macro for every cue list you want to release. I rather would like to be able to set the time direct to relaese in a macro.
I think what SBC is saying that. When using a new cue list 2/x with an effect. The effect that was running on the background cue 1/x has been asserted. And when the second cyelist is released the old effect is not working any more. But in fact the background cue 1/x that you want to take over again should be working as a LTP and start working again.
Marnix