• Date
    Crispy
  • Date
  • Replies 14 replies
  • Subscribers 183 subscribers
  • Views 16987 views
  • Users 0 members are here

Mark and Partial Block

Hi all,

First off: coming from an Obsession 2 background, I understand the reasons for blocking channels in cues where they have been recorded at the tracked level, i.e. if channel 1 goes to full in cue 1 (and tracks) and when recording cue 4, channel 1 is recorded at full, then a partial block appears on that channel. Having the block is a good way to know that there is a redundant ‘hard’ command in that cue.

That’s fine, it can be slight tedious to clear all those blocks but essentially … fine.

Now (unlike when programming the Obsession 2) when I’m recording cues with moving lights, I will create the state, record it and then mark all the moving bits.

In this example, channel 1 in cue 4 moves to FP1. If I mark channel 1 in cue 3 then I get partial blocks on channel 1 in cue 4.

Surely the raison d'être of mark is to make sure the NIP’s are the same in the previous cue. Therefore, is the block not redundant (unsightly and a bit of a pain in the bum)?

My understanding of tracking is that data recorded will track ahead until it hits a point where it is told to change. Therefore, if you change the light upstream in the cue list, the data will track on until it hits the downstream cue, then it will change.

So my question is… why does mark create the partial block, as its function is to make sure that the NIPS are in the previous cue?

Also, does this become redundant when I can [system blocks: disabled]?  

Sorry for the long post

Crispy

Parents
  • Hey Chris.  Couple of things here. 

    We will .... at some point in the near future .... provide a utility that allows you to isolate all of the auto-blocks (or system populated blocks, or those blocks with the white underscore.....) and clean them up at one time, so you don't have to manually hunt them down.   But is also one of the reasons that a system applied block looks different from a user applied block.  

    When you mark a light, a block is automatically applied to any parameters of that light that are tracked values.  This is because we assume when you mark the light (or the parameter or parameter category) you want to make sure that exact condition is preserved - and that it will mark in that state when told to mark.  Even if this means that there is no actual change to that parameter because it was tracked.  I realize it may seem a bit odd, but it is a way to assure the light is going to mark to EXACTLY the condition you see it in when the light is active.... and that this condition is protected from changes to the data upstream.      You kind of have to think of referenced marks like reverse track instructions.  The move is actually stored in Cue 4 (so the data is stored and protected in cue 4).  The move OCCURS in cue 3, because that's where you told the light (you gave it this information in cue 4) to mark.    So, the block is applied where the move is stored (Cue 4).  

    Question:  Is your concern that the data is blocked?  Or is your concern that the data is blocked in Cue 4?  That might help narrow the discussion.

    Thanks!

    a



    [edited by: Anne Valentino at 7:33 PM (GMT -6) on Fri, Oct 12 2007]
  • in reply to Anne Valentino

    Okay, so I understand that the hard command on cue 4 is the reference for the cue and the reference for the mark and that is marvellous.

     

    In addition, although there is a difference between a user asserted block and a system applied block on the channel number, it’s not a huge one. My concern is that it is displayed as a block in the cue list, which is untidy and often hides the blocks that you asserted and want to see.

     

    Putting a partial block on every mark is going to be counterintuitive in a mark-heavy show.

     

    Cheers Josh for explaining the Expression reasoning. It’s good to know the history behind why things have happened.

     

    In summery:

     

    1)      Yes, if there is a redundant hard command it should show up as a system applied blocked channel in the channel page.

    2)      However, I’d prefer it if it wasn’t displayed in the Block section of the cue list.

     

    And my main concern…

    3)      Marks will only ever preset the same values so why display them as a block. It’s unnecessary information.

     

     

    Of course this is just me. If everyone else is happy then I’ll learn to live with it. If there are others, I’ll start a facebook petition!

     

    Thanks for reading. Crispy

  • in reply to Crispy
    Crispy:

     

    And my main concern…

    3)      Marks will only ever preset the same values so why display them as a block. It’s unnecessary information.

     

    Thanks for reading. Crispy


    But it isn't necessarily unnecessary information Chris.  (Sorry, that sounds pretty weird....but.... )

    Cue 1 - VL500s on the sofa, in R80, zoom at 50%.  Intensity ff.    Tracks forward until cue 4 - where you set them out.  In cue 10, they are going to fade up, again on the sofa, zoom at 50%, but in R02.   In cue 10, mark the lights back to cue 5.    When you mark, unless you do a selective mark, you are marking the entire state of the light.   So, Focus and Beam are going to be blocked.   As is, there will actually be no presetting of those parameters, as they are unchanged from the last time the light was active.  However, if you go back to cue 1 and put them DSL, as long as you still set them out in cue 4, they will mark in cue 5 and come up in cue 10 on the sofa.  

    Let's put the question you are asking in very clear terms  - Should tracked instructions be excluded from a channel level mark?   By default, then, only the move instructions are going to have a mark flag - the tracked values are just tracked values, and the complete setting of that light will not be protected from changes upstream in the cue list?    Hmmmm... seems like a pretty big jump ball.  We went with the default decision that was the safest.   If you don't want the entire state of the light to be protected, you can do a selective mark.     This is one of those things that can be argued both ways.....I think?

    Thoughts everyone?

    a


    [edited by: Anne Valentino at 7:34 PM (GMT -6) on Fri, Oct 12 2007] [edited by: Anne Valentino at 7:32 PM (GMT -6) on Fri, Oct 12 2007] [edited by: Anne Valentino at 8:51 AM (GMT -6) on Fri, Oct 12 2007]
  • in reply to Anne Valentino

    Fair point, if the value is a tracking value there still needs to be a Hard value at the cue point so that the state is preserved. (Good example by the way) And its not that that I had a problem with – or was it?

     

    What I was finding was this:

     

    The light was being used for the first time, when I marked it to an earlier cue it partial blocked. Seemingly looking like the mark function was asserting its function as a hard command.

    Now, it was a long time ago however, it was during a demo and it was the first time I was explaining mark that day so there shouldn’t have been any previous information in the cue stack.

     

    If the values were already recorded in that position then, yes I couldn’t agree more, there should be a partial block. If the light was being used for the first time in the cue list, then it shouldn’t have a partial block unless I go earlier in the cue stack and ‘trace’ the values. Am I correct in that assumption?

     

    Crispy

  • in reply to Crispy
    Chris, the first use of the light in the cue list should have all move instructions for that light.     And if you trace the value back to an earlier cue, you should end up with a tracked value in the later cue.   

    ??

    a
  • in reply to Anne Valentino

    We need to fight this out over a glass of wine.

    If you trace the values, yes you get a partial block. Thats what I'd expect.

    If you mark a light that wasn't system enable blocked (because it has no hard commands earlier in the cue stack) , why does it partial block when you add the mark function?

    I'm obviously not being very clear. Sorry

  • in reply to Crispy

    I tried this out in a few ways, and I can't reproduce any scenario where marking a parameter, that has not yet had a move in the cuelist, creates a partial block. If it is doing this in some scenario, it's a defect, but I don't see it happenning in 1.2 release code, when I try it here.

     In this scenario, the parameter that you are marking should be displayed as a move (blue). The only time it should be displayed in white (block) is when it was tracking a move from a previous cue, and it gets a new instruction (to mark), because in this case the marked level will be equal to the tracked level, so it displays in white.

Reply
  • in reply to Crispy

    I tried this out in a few ways, and I can't reproduce any scenario where marking a parameter, that has not yet had a move in the cuelist, creates a partial block. If it is doing this in some scenario, it's a defect, but I don't see it happenning in 1.2 release code, when I try it here.

     In this scenario, the parameter that you are marking should be displayed as a move (blue). The only time it should be displayed in white (block) is when it was tracking a move from a previous cue, and it gets a new instruction (to mark), because in this case the marked level will be equal to the tracked level, so it displays in white.

Children
  • in reply to Dan Duffy

    Thanks, I was hoping it was a defect.

    Thank you all for taking me on the Partial block journey.

  • in reply to Crispy
    Always a treat.... but you are right, some conversations require a glass of wine .... and a white board.   Too much discussion of blocking (which seems like SUCH a simple idea), marking or out of sequence cues on a tracking console all falls into that category.    At least we can go through the discussion multiple times and come to the same conclusion.... so I guess that's a good thing!!

    Thanks for helping to keep us honest!

    :)

    a

  • in reply to Dan Duffy

    Chris, All, 

     Check this out and see if its whats causing your partial blocks:

    When marking all parameters you sometimes get a partial block on the fixture the first time it is used.  This is true of attributes that are marking to home positions that you might not be looking at.  For example Mspeed or, the big one for me has been Color Brightness on fixtures with scrollers.  VERY frustrating to have this HSI data in the cue stack for scrollers I keep on getting partial blocks and having to expand the data or switch views to find out which attribute is blocked.  I have another post regarding this issue somewhere....

     

Related

www.etcconnect.com