• State Not Answered
  • Date
    litedesign
  • Date
  • Replies 16 replies
  • Subscribers 189 subscribers
  • Views 17313 views
  • Users 0 members are here

Feature request: Release Cuelist after last cue

It would be great if a cuelist could be designed to Release itself when you press the go button from the last cue.

It would also be nice if Assert time could be adjusted so as to allow a moving light with intensity 0 to move back to its previous position before fading up when the cuelist that was using the light is released. Perhaps a separate timing function for Release Time, and an intensity delay?

Parents
  • 0 in reply to Nick Simmons
    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.
  • 0 in reply to Marnix Kuling
    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.
  • 0 in reply to litedesign
    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.
  • 0 in reply to Nick Simmons
    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
  • 0 in reply to Marnix Kuling
    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
  • 0 in reply to Marnix Kuling
    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.
  • 0 in reply to Marnix Kuling

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

  • 0 in reply to Anne Valentino
    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
  • 0 in reply to Anne Valentino
    EOS states that control exists somewhere or nowhere.
    If I record a cue that includes NP data and leave it active then I record a submaster that includes NP data from the same fixture(s), when I play back the submaster, the "ownership" of the data is currently from the sub. When the sub is down, (released) the ownership is transferred to the last active cue.

    If there is no active cue list and we follow the same path, when the sub is released, the NP go back to their home state.

    I learned LTP as NP hold their last state dependent on the type of playback most recently executed. Kind of like the difference between GO TO CUE 0 vs GO TO CUE OUT.

    If there is no output from the console other than the HOME state, then I record a submaster as above, and run the sub to 0 (release it) the NP values currently go back to their home state. Same as with GO TO CUE OUT.

    I submit that true LTP behavior would be the following:
    If there is no output from the console, then I record a submaster as above, and run the sub to 0 (release it) the NP values hold their last state until another cue, submaster, or manual value is asserted to them . Same as with GO TO CUE 0.

    This should also be true for cue lists. Or at least allow a toggle state for when a cue list is released that all NP values remain at their last given value OR the revert to their home state.
  • 0 in reply to SBC

    Thanks. Trying to pickup the various thoughts here:

    When a cue list or submaster steals control from a cue/sub running an effect, and that cue/sub is then released to background, the effect in the initial cue/sub is restarted. There is no need to force this - it just happens (this was changed in ....errr... 2.3.2???).

    With the changes in 2.4, it would certainly be possible to extend timing defaults to content/fader behaviors in the future. First step was removing the release timing from the assert time and making it it's own thing. We will ponder extensions to this post 2.4.

    Steve, I've never actually considered Hold Last Look and LTP to be related - interesting. Hold Last Look (in ETC -land) is a specific command (seen in receiving devices) to determine behavior when a control signal is no longer present. As you know, within the console, when content is released to background, if there is no content in the background - it is homed. This is the nature of the release feature and is irrespective of LTP rules. It seems what you are looking for are optional release behaviors. The list here could be never ending, so maybe we could narrow down the immediate request?

    Upon Release:
    1) Send intensity and NPs to Home (Go to Cue Out)
    2) Send intensity to home (zero) and leave NPs in state (Go to Cue Zero) (I believe this is the behavior you are after?)
    3) Send intensity to background state (potentially that means home them) and leave NPs in state
    4) Send intensity and NPs to background state
    5) Send intensity to background state. Send NPs to background if present or leave in state if no background.
    6) I'm sure there are more combinations and if/this statements that could be developed.

    Is it fair to say that if we were to provide a release behavior that duplicates #2, you'd be happier?

    Thanks much.
    Anne

Reply
  • 0 in reply to SBC

    Thanks. Trying to pickup the various thoughts here:

    When a cue list or submaster steals control from a cue/sub running an effect, and that cue/sub is then released to background, the effect in the initial cue/sub is restarted. There is no need to force this - it just happens (this was changed in ....errr... 2.3.2???).

    With the changes in 2.4, it would certainly be possible to extend timing defaults to content/fader behaviors in the future. First step was removing the release timing from the assert time and making it it's own thing. We will ponder extensions to this post 2.4.

    Steve, I've never actually considered Hold Last Look and LTP to be related - interesting. Hold Last Look (in ETC -land) is a specific command (seen in receiving devices) to determine behavior when a control signal is no longer present. As you know, within the console, when content is released to background, if there is no content in the background - it is homed. This is the nature of the release feature and is irrespective of LTP rules. It seems what you are looking for are optional release behaviors. The list here could be never ending, so maybe we could narrow down the immediate request?

    Upon Release:
    1) Send intensity and NPs to Home (Go to Cue Out)
    2) Send intensity to home (zero) and leave NPs in state (Go to Cue Zero) (I believe this is the behavior you are after?)
    3) Send intensity to background state (potentially that means home them) and leave NPs in state
    4) Send intensity and NPs to background state
    5) Send intensity to background state. Send NPs to background if present or leave in state if no background.
    6) I'm sure there are more combinations and if/this statements that could be developed.

    Is it fair to say that if we were to provide a release behavior that duplicates #2, you'd be happier?

    Thanks much.
    Anne

Children
Related

www.etcconnect.com