• Date
    joshgubler
  • Date
  • Replies 3 replies
  • Subscribers 183 subscribers
  • Views 7322 views
  • Users 0 members are here

Unwanted blocking

Suppose the following situation:

in cue 12 channel 1 goes to 50% and tracks.  I later realize that I need that change to happen in cue 11.  I make the change in cue 11.  What happens to the value in cue 12?  On the O2, channel 1 is blocked at 50% in cue 12.  This is obviously the correct solution as the console doesn't know that I want the value converted to a tracked value...but it gets in the way when you later decide you want channel 1 at 60% in cue 11 to track, and the track doesn't take.  So does the EOS behave like the O2 here?  Is there a way to say "track and if you see the same value, don't block (i.e. remove it)"?  Or is it simply a matter of "moving" the change from cue 12 to cue 11?

I'm also curious if there's a way to do this on the O2...my current solution is to manually remove the block from cue 12, but it would be nice to do it all in one stroke with the record.  I see a button that says "track thru", but that seems to be unimplemented. 

I run into this most when presetting scrollers and movers...I guess that problem goes away with mark and reference.

Parents
  • Hi Josh.  

    At this very moment in time, if you did the action in the first paragraph, the channel will be blocked in cue 12.   So you would, in fact, need to remove the block manually.  In an upcoming software release, we will add a "move" function on a per channel/per parameter basis.  So, when the data is moved from cue 12 to cue 11, it is nulled out in cue 12, and hence becomes a tracked value from cue 11....... unless you "move cue only", in which case it would place a move equal to the value the channel was at before cue 11.

    Also, in some future build, we will implement a setup option called "AutoBlock Enable/Disable".     While we both seem to think that the system automatically protecting your move instructions by placing a block if the value upstream is changed to match that move is the desired behavior..... some people actually consider that behavior (which is also how O2 works) a bug.  And certainly, if you don't understand why the system appends the block, it can be confusing.   So, at some point, you'll be able to disable that feature.

    On O2, you have to manually remove the block.  You might try making the change in blind as a range selection.  So, go to blind spreadsheet, select your cues, select the channel you need and make the change.  I haven't worked with Obsession in a while though, so I'll ping an expert to see if he can give you any additional input.  

    On Eos, you have a couple of options, based on how you are making the change.   If you make the change in blind through a range of cues (as above), that channel will have a tracked instruction through that range.... unless it was blocked in a specific cue.   If it was already blocked, the new value will be applied, but the block will be maintained.  If you make the change through a live update [update] [11] [thru] [20] [Enter] - any move instructions or blocks in cues 12 thru 20 are removed, and the channel modified to the new instruction through the range. 

    Hope this helps.

    Anne


    [edited by: Anne Valentino at 9:43 AM (GMT -6) on Sat, Jul 21 2007] [edited by: Anne Valentino at 8:46 AM (GMT -6) on Fri, Jul 20 2007]
  • in reply to Anne Valentino

    Thanks Anne.

    Wow, "AutoBlock Enable/Disable" as a global setting...that's dangerously powerful.  I think a lot of people who think this is a bug will have a sharp awakening when their automation is "changing on its own."  We're really getting to the point with these consoles where users have to be actively aware of how data is stored and manipulated.  You have to start writing your cues defensively, putting blocks in deliberately "just in case we go back and change the last scene."

    Being able to "move" a value makes sense, I'm glad you're adding that.  And being able to update a range is slick too.

    On the O2, if you use a range selection in spreadsheet to set the values, I'm pretty sure it blocks each value in each cue.  Which isn't too bad because it's then very easy to unblock the selection specifically.
     

Reply
  • in reply to Anne Valentino

    Thanks Anne.

    Wow, "AutoBlock Enable/Disable" as a global setting...that's dangerously powerful.  I think a lot of people who think this is a bug will have a sharp awakening when their automation is "changing on its own."  We're really getting to the point with these consoles where users have to be actively aware of how data is stored and manipulated.  You have to start writing your cues defensively, putting blocks in deliberately "just in case we go back and change the last scene."

    Being able to "move" a value makes sense, I'm glad you're adding that.  And being able to update a range is slick too.

    On the O2, if you use a range selection in spreadsheet to set the values, I'm pretty sure it blocks each value in each cue.  Which isn't too bad because it's then very easy to unblock the selection specifically.
     

Children
  • in reply to joshgubler
    Josh.... yes, it is extremely powerful.  Probably the only other user default on the desk of equal significance is Cue Only/Track.  All of the other defaults are reasonably benign and don't impact your show data in any critical manner.  Autoblock is Enabled by default because it does provide a higher level of protection.   But some people truly do not want the desk to assign blocks for them; so, they have that option.

    And I agree with you.   At the speed we have to work at, with so many devices to control, its hard enough to keep your show accurate and clean; not understanding clearly how the desk is "thinking" really compounds the possibilty for mistakes.... and is dangerous.  That's actually one of the reasons ETC have started teaching Control Philosophy classes.

    The O2 spreadsheet behavior you describe was actually a bug that was fixed in a release last year.  If you really did want to block all of your selected channels in blind, is easy enough to do - so we separated it from range edits.  That one bug was probably why we got such an earful about auto-blocking when Eos was being specified.  :)

    Take care!

    a



    [edited by: Anne Valentino at 8:26 AM (GMT -6) on Sat, Jul 21 2007]
Related

www.etcconnect.com