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

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

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