• Date
    Crispy
  • Date
  • Replies 14 replies
  • Subscribers 183 subscribers
  • Views 16979 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

    hoi

    -trying to keep up with your discussion, and will try not ruining it... ;)

    A utility that allows me to isolate all of the auto-blocks and clean them up at one time would be very nice. So that lazy guys like me who uses auto-mark can keep my tracking sequences "clean" even if I use a lot of [update][Q-only] for not ruining later cues in that sequence when made. But when a [Q-only] registration later on is moved to a earlier cue in the sequence, I really want to get rid of the first made partial block (if changed values in next cue; is enough) to track clean thru the sequence next time. If I want to be absolute sure that exact condition is preserved forever I rather make a big Block.

    - But can I please have an opportunity to give auto-mark a delay? VL1000 fx: with int down time =0 starts pre-setting gobos long before the slow mechanical dimmer has closed. (If I already have, I can't find it.)

    keep up

    tøis 

     

  • in reply to tryggve
    tryggve:

    hoi

    -trying to keep up with your discussion, and will try not ruining it... ;

    tøis  


    Happy to have you join in!  We've talked a bit fixed timing on some devices when marking, for exactly the reasons that you mention.  Right now, there are two options .... You can use discrete timing or cue level timing.  The basic rule for marking (either automarks or referenced marks) is that if the lights have discrete timing, they will use that timing regardless of when they preset.  If they do not have discrete timing, they will use the time of the cue in which they will actually move.

    So, lets say the data for the move is stored in cue 10, and you are using auto-mark, so they will preset in cue 9.  If there are no other beam transitions in cue 9, you can put a delay/time at the cue level:  Cue 9 Beam Delay 2 (or whatever).... also, obviously you could put a transition time.  If not, the beam category will delay 2 seconds and then use the default beam time.    If there is other stuff happening in beam in cue 9, you can then use discrete timing.

    So, in cue 10, assign a delay/time to the parameters you need to delay.  When they mark in cue 9, they will use that timing.

    Does that make sense??

    a
Reply
  • in reply to tryggve
    tryggve:

    hoi

    -trying to keep up with your discussion, and will try not ruining it... ;

    tøis  


    Happy to have you join in!  We've talked a bit fixed timing on some devices when marking, for exactly the reasons that you mention.  Right now, there are two options .... You can use discrete timing or cue level timing.  The basic rule for marking (either automarks or referenced marks) is that if the lights have discrete timing, they will use that timing regardless of when they preset.  If they do not have discrete timing, they will use the time of the cue in which they will actually move.

    So, lets say the data for the move is stored in cue 10, and you are using auto-mark, so they will preset in cue 9.  If there are no other beam transitions in cue 9, you can put a delay/time at the cue level:  Cue 9 Beam Delay 2 (or whatever).... also, obviously you could put a transition time.  If not, the beam category will delay 2 seconds and then use the default beam time.    If there is other stuff happening in beam in cue 9, you can then use discrete timing.

    So, in cue 10, assign a delay/time to the parameters you need to delay.  When they mark in cue 9, they will use that timing.

    Does that make sense??

    a
Children
Related

www.etcconnect.com