• Date
    Crispy
  • Date
  • Replies 6 replies
  • Subscribers 186 subscribers
  • Views 14961 views
  • Users 0 members are here

Updating cues and releasing channels

Dear All,

 

Please bear with me; it’s a little hard to explain…

If you select a channel and manipulate it (or force manual data) it turns red to indicate that the levels are not recorded. If you update the cue, they turn blue. Great. If you update a previous cue and the values track through the Live cue or Update a later cue and the values trace back then the manual data will be stored and, again, the display turns blue.

However, if you change a parameter and update a range of cues that don’t affect the Live cue then the manual values are still kept ‘active’ (i.e. displayed red) and you can keep recording/updating palettes till your hearts content.

If you update a previous cue and some values track through the Live cue then you lose those active channels but the channels without data in the Live cue are still controllable (i.e. they stay red and don’t turn blue).

 

The only problem that I had found was that I wasn’t aware this was happening and it would be very easy to think that after you have pressed update/record that all the values are null. If they’re not then you run the risk of updating lights when you don’t mean to. A possible excuse for ‘Shift Clear’?

 

Thoughts anyone? (If you still with me or haven’t fallen asleep with boredom)

 

Cheers, Crispy x

  • We call this behavior of converting from manual (red text) to playback (blue text)  "Autoplayback on record". The intent is that if the level for the channel is equal to the level in the active cue, then it should be blue not red. The following are all of the cases where that happens.

    It only happens on a cue record if:

    1) it's either a full record (no channel list list included in the record), that cue now becomes the active cue

    2) a record that creates a new cue that follows the active cue, that cue now becomes the active cue

    3) a record to the active cue (this includes update enter)

    4) a record to the source cue for a channel that is tracked in the active cue

         Ex:active cue 5 chan 1 tracks cue 3's chan 1 level, and you record to cue 3

    The first 3 are all or nothing, meaning either all or none of the channels included in the record are autoplayed back. But #4 can leave some channels red, because they contain moves not tracks in the active cue.

    This doesn't answer the problem of your not knowing that some channels may still be manual (red), but it may help this discussion to explicitly list the rules that Eos is following. 

  • Hey Chris.  I think the current behavior of the desk is the only way it can work.    If you update to a previous cue - and that cue was (or becomes) the source of the move for some of the lights in the update but there is a move instruction in between the current cue and the updated cue for other lights, you will end up with some values magenta and some in red.  

    I'm not sure what you mean by this statement?

    The only problem that I had found was that I wasn’t aware this was happening and it would be very easy to think that after you have pressed update/record that all the values are null.

    Huh?

    :)
     
  • in reply to Anne Valentino
    Hello folks...

    Crispy and I discussed this the other day. In answer to Anne's 'huh?!?'... if I understand correctly, Crispy's worried by having manual data left over that he might subsequently include in an update un-intentionally. Ironically, my concern is just the opposite... I'm worried about the stuff that's been taken from my manual data selection and converted to playback data!

    On other desks that I've worked with, manual data in Live is usually retained until the operator/LD decides that the data selection is no longer required - at this point a command is issued to deselect/release/un-capture the manual data (sorry, this is tricky to write about because all these terms are loaded, and mean slightly different things depending which desk we're talking about!).

    So, on a '500' Series the operator might [Load][Cut] the cue (this re-runs the cue in Live, thus losing the selection and returning all the manual data to cue level). Crispy mentions [Shift][Clear], which in its '500' Series incarnation nullifies the manual data (althought it differs from [Load][Cut] in that any channels that differ in level to the recorded cue are not reset to cue level). More 'American' -style desks might use some kind of releasing syntax (cue my face of fear!).

    What worries me is that I work with quite a few lighting designers who regularly use the stage as a 'holding location' for a set of modifications that they then update to various different places in the cue list. This would usually occur when we're modifying the lighting state for an on-stage location that occurs several times during the show - any changes made to the base state potentially need to be updated to the cues for the other times that we visit that same location.

    For example, the RSC is currently shadow-plotting with Eos on '12th Night'. If we modify the lighting state for the opening scene (which is set in the House Of Count Orsino) there's a fair chance that at least some of those changes will need to be updated to the other occasions when we go to the House Of Count Orsino. Many lighting designers tackle this by modifying one of the cues onstage, and then saying something like: 'Ok, update cue 1'... (pause to leaf through script) 'Ok, also update cue 15'... (more paper-shuffling) 'Ok, and update cue 76'... and so on! This approach works because the manual data remains manual until the LD or programmer clears it.

    On Eos this is potentially a problem because the moment a cue within tracking/tracing distance is updated, things in the manual selection onstage will start to convert to playback data. If the first cue updated is the onstage cue, the entire selection will convert! If the selection is a very simple one this may not be too much of a problem - I can reselect the channels and off I go. However, if the modifications comprised a large number of changes made over 15 minutes or so, the process of identifying the relevent channels to reselect them may not be either quick or straightforward.

    Maybe what this comes down to is asking the desk to predict what our future intentions are for a set of onstage modifications... now this might seem like a bit of a tricky mission! However, there are some instances where I think "Autoplayback On Record" already does this rather neatly:

    In Dan's scenario (1) we're doing a whole stage record. If the LD is thinking of the modifications in terms of a whole stage record, its comparatively unlikely that s\he will suddenly start wanting to update the mod's to multiple places around the cuelist - this isn't how they've been conceived, and it probably wouldn't make 'lighting sense'. So in this case I think that "Autoplayback On Record" is rather neatly suited to the situation.

    Similarly, in Dan's scenario (2) we're recording an entirely new cue from a modified onstage cue. Again, the LD has conceived of the modifications in context of a whole stage record, so its unlikely that s/he will suddenly start trying to update them all round the cuelist. So again, "Autoplayback On Record" seems like the ideal solution.

    However, scenario (3) is trickier... if I'm in the middle of running a cue sequence, and I make a couple of quick modifications 'on-the'fly', [Update][Enter] followed by "AutoPlayback On Record" is exactly the behaviour that I want. However, if I spend twenty minutes modifying a cue in a lighting session, I'm not so sure that "Autoplayback On Record" is necessarily the right solution - this is the kind of scenario where the lighting designer might want to target the modifications to more than one cue. But I'm not quite sure how Eos is supposed to know that!

    Finally, in scenario (4) where I'm not updating the current cue, but may hit a cue within track/trace distance of the onstage cue, I think parts of my manual data selection disappearing is the last thing I'd want! So for me, if I'm not directly updating the onstage cue, I'd find "Autoplayback On Record" to be the wrong behaviour. If I'm updating modifications round the cuelist, Eos doesn't have a hope of second-guessing what I'm going to do next, so I'd rather it didn't try and left all manual data alone until I decide to clear it manually (which would probably put me in the pro-[Shift][Clear] camp with Crispy!)

    So, in summary: I love "Autoplayback On Record" in scenarios (1) and (2). It scares me silly in scenario (4). However, if "Autoplayback On Record" was removed from scenario (4) I'd be inclined to leave it implemented in scenario (3). This would mean that when updating modifications to multiple cue locations, my manual selection would never be stolen away - with the proviso that I would need to remember to always update the onstage cue last.

    The End! Sorry all, that's the longest post in the world... :-)
  • in reply to Andi.Davis

    Having made my way through Andi's eloquent post, I was wondering, if you were wanting to (excuse my French) 'release' the channels to move on and do something different, would it be so bad just to [sneak] [Enter]. Yes, its likely that there may be some movement on the rig, but at the point of 'releasing' (yes, I giggled too) you're likely to be moving on for example to a different cue.

    Therefore my problems lies with not knowing definitively which channels i have active/manual at what point.

    Also, if you were updating a number of different cue ranges, you could do this in one syntax in Blind...This then leads to an '@ Live' function...but that is surely another post?

    Thoughts on '@ Live'?

    Crispy x

  • in reply to Crispy

    Is there a quick and easy way to select only the manual (red text) channels and record them off to a temporary group?  Then this group can be loaded into each of the cues.  This is how I've dealt with this Andi's issue on the O2, which also uses "Autoplayback on record".  Or if it's a simple block of channels, can you set the channels "at group cue x".

    About Crispy's concern...it seems that re-loading the current cue would remove manual data.  Try using "goto cue x".  I don't know how this works with multiple cue lists, though.

  • in reply to Andi.Davis

    Hi All

    A very thoughtful post Andy.

    Just trying to think of away around this.

    If before updating the first cue you used [Select Manual] and then updated the current cue. Once the “Autoplayback On Record” had completed you could then use [Select Last] and this would hopefully select all the manual channels from before the update??? Once these channels are select use {Make Manual} and then updated all the other cues in the other locations.

    Obviously this would require the LD to tell you before you updated the first cue, but you could use undo in that case.

    I have not tried this to see if it works and it’s not ideal, but it maybe a work around which shouldn’t take to much time.

    Crispy I’m a big fan of @Live, but maybe we can push for [Recall From] [Live] as the way to go on the Eos?

    Nick



    [edited by: Nick Simmons at 3:57 PM (GMT -6) on Sat, Sep 01 2007] [edited by: Nick Simmons at 3:56 PM (GMT -6) on Sat, Sep 01 2007] [edited by: Nick Simmons at 3:55 PM (GMT -6) on Sat, Sep 01 2007]
Related

www.etcconnect.com