MARK EARLIEST not functioning as advertised

Actually, what the manual states is this:

The {Earliest} command can be used with [Mark] to mark the channel into the cue after the last

intensity moved from a nonzero level to 0. The mark is stored and behaves exactly as if you had

typed the cue number instead of {Earliest}

As such, that the mark earliest command marks to the cue after the light moves to zero is correct.  And I believe, is as advertised.  If you want to mark to the cue where the light is also fading to zero, you will need to do that by entering the cue number that you want.  We will look to clean that language up to make it less confusing.  

I'm not clear on your complaint about another go being required.  The cue the desk WILL mark to already exists, and is going to be executed by SOME action - and presumably there is something happening in that cue other than just the mark.  Meaning neither the cue nor the Cue Go is superfluous.   You can control the timing of the mark by using discrete timing if needed.  Please explain?

Hope that helps.  Thanks!

a

Actually, what the manual states is this:

The {Earliest} command can be used with [Mark] to mark the channel into the cue after the last

intensity moved from a nonzero level to 0. The mark is stored and behaves exactly as if you had

typed the cue number instead of {Earliest}

As such, that the mark earliest command marks to the cue after the light moves to zero is correct.  And I believe, is as advertised.  If you want to mark to the cue where the light is also fading to zero, you will need to do that by entering the cue number that you want.  We will look to clean that language up to make it less confusing.  

I'm not clear on your complaint about another go being required.  The cue the desk WILL mark to already exists, and is going to be executed by SOME action - and presumably there is something happening in that cue other than just the mark.  Meaning neither the cue nor the Cue Go is superfluous.   You can control the timing of the mark by using discrete timing if needed.  Please explain?

Hope that helps.  Thanks!

a

You did not mention the example given in the manual... 

Mark Earliest

As to your confusion, if the light doesn't mark on the fade out cue, you have to  wait for the stage manager to say GO again before the lamp starts marking.

Also , as the manual text indicates, the console will mark to the fade out cue, but only if it is the "cue immediately before the cue being marked".  An ETC choice , I presume?

What is your definition of EARLIEST?

Oops.  Fair enough.  I didn't actually read the example.  We will get that fixed as it is indeed incorrect.  Sorry about the confusion. 

"Also , as the manual text indicates, the console will mark to the fade out cue, but only if it is the "cue immediately before the cue being marked".  An ETC choice , I presume?

What is your definition of EARLIEST?"

Our definition of earliest is the cue immediately after the light fades to zero.  That's the reason that we call out the exception to that rule -  which is if you are marking a light, and that light is fading to zero in the preceding cue, we will mark to the preceding cue, as there is no other place to put the mark.     We made this choice as many programmers don't like marking to the cue where the lights are fading out as well, unless there is absolutely no other choice.  

It's been suggested to us .... and I think I agree.... that a better use of mark earliest would be to mark to the earliest cue that already has a mark flag, rather than just the earliest possible cue.  If you are using referenced marks, you generally care very much about where the lights are marking, and will make this determination by placing mark flags in show-appropriate locations.   We may, therefore, change the mark earliest function, or provide a second softkey for this purpose.

Again, sorry about the manual confusion.  Hope that helps.

a

Hi Anne

I'd definitely be a tick in the 'yes please' box for  'mark to earliest flag' as either a function or button!

Also, is there a way that we could do a user-definable time for marking (ideally by parameter/fixture type) or an allowable syntax along the lines of...

ch1 Mark Earliest Time 2* (or Mark Time 2*) which could maybe assign a discreet time automatically for fixtures/parameters marking.

I do find myself digging around to find what times things are marking in, where I'd love to know that I can define it by syntax quickly.

Does that make sense at all?!

Loving your work!

Warren.

Warren, we are looking at a couple of things.  1) Default mark time.  This would be established in setup.  At the moment, it is conceived as one time for all mark values ... not based on parameter category or type.  If default mark timing were enabled, the only way to override that would be to use discrete timing.  2)  Appending a discrete time instruction to the mark command.  This would just be a syntax extension. 

Hope that helps.  Thanks for the kind words!! 

:-)

a

I just programmed a show using the following macro:

(ch 1)  FOCUS COLOR BEAM TIME 9 DELAY 1 MARK EARLIEST<ENTER>

This worked almost all the time until the cue intervals got tighter and I had to have a fast version. The delay is for douser lag, just in case the mark cue landed on a fade out.

It works in blind too.

It would be nice if discreet timing was shown in a different color in the mark cue, since it can only be changed in the reference cue, I got fooled a couple of times trying to change it in the wrong place.

So now its May 2012 and we now have MARK EARLIEST MARK  (see Ann's posts on this thread).   At first it seemed to improve on the shortcomings of MARK EARLIEST, but as of V 1.9.9, it's power has been watered down. I noticed this when it seemed I never got an error message when using it, and at the end of tech there were a whole lot of mark cues I never designated, because it created new ones without any comment at all. Also, EARLIEST MARK seemed to suffer the problem of not marking upstream of block cues, the same problem MARK EARLIEST had.

This means that if my half hour preset is my first MARK cue, EARLIEST MARK will not reliably put a mark there if there is a blocked blackout cue in between (there almost always is). I would assume most designers would prefer a big mark cue happened before the audience came in, rather than the first scene of Act I. I guess for now I will have to intervene manually to assure a satisfactory outcome.

This was mentioned to me the other day actually, but I hadn't had a chance to try and reproduce it yet. I haven't seen it myself, but it was mentioned that 'recently' Earliest M isn't always marking to the earliest mark cue available. I expect post 1.9.8.

Dan

So, in trying to reproduce the problem, I found it can be caused when Earliest M can't find a useable mark flagged cue, it flags one  (whether it should do this is an issue itself). In doing so a mark cue is chosen for the first channel in the list.  if this mark cue satisfies the other channels then no earlier marking is done for them. 

So if the command:

->Chan 1+2 Mark Earliest M *

marks 1 in cue 1 and 2 in cue 3, where no mark cues have been flagged already, the comand:

 ->Chan 2 + 1 Mark Earliest M *

 would mark both in cue 3, given the same situation.  While you wouldn't do this in blind, most likely, you stand a good chance of doing it in Live since the mark commands don't need to occur in the same sentence. Which ever one is marked first before Update controls the outcome.

This can be reproduced using Live or Blind marking. 

The blocked cue issue seems to be caused by something I noticed several versions earlier, though denied by ETC. 

If you have a few redundant white zeros  in a cue, toggling the block state will erase them, BUT new ones can be created afterwords, either by direct command (Chan 1 @ 0), or, more likely, a cue change upstream caused a green move to zero, and then was changed back, leaving the redundant move in place.  The presence of this can be seen with the query command.  Take a blackout cue (say cue 2) and toggle the block state to B.  Type "Query 2 *  " and only the white zeros should not be selected.  Then add some redundant moves (say Chan 1 thru 10 @ 0), and query again.  You should find channels 1 thru 10 now added to the selection, indicating a move to zero instruction hidden behind the generic Block colorizing.  This move to zero prevents Earliest M from marking further upstream.  This problem only applies when the global mark flag is "B:" or "I".

There are some other reasons my first cue in the list was rejected as a mark by MARK EARLIEST (M). One is  if the intensity is null, and the other is if it is a blue zero, seen by the console as a move to zero, therefore rejected.  The solution was to have a  cue 0.5 with all parameters having a level (blue zero...etc), then cue 1 is seen as a normal cue.