Mark - Earliest M - Rule change...Strongly Disagree!

And I, for one, was going to post how I love the change. I never want the console to create m's for me, ever. Now if I mark a bunch of lights as earliest m I no longer have to go back and make sure the console did not help me by creating an m that won't work.

I've just been doing some testing in 2.2 and 2.3.2.

The SCR had some wrong information in it, the SCR was written that in 2.2 if it couldn't find a Mark point it would create a new mark point the cue before the reference point, so the same as a broken mark. This is wrong and in 2.2 it doesn't mark in the cue before but works the same as Mark Earliest and makes a new point the cue after it's faded out.

I don't use Earliest or Earliest M so this has never affected me so I'll let people that use it fight over it. I want a more advance feature but I'm still waiting (Anne's stopped talking to me anyway [:'(]).

Warren can you confirm the problem with the part 20 macro.

I can get a macro to work and fix all the broken marks you may just need to change the syntax.

Andi, lucky at getting Mark changes in the code, I've tried for 8 years with very limited success!

Thanks for posting Jay and Nick. I've also been doing a bit of canvassing opinion offline and again responses were divided.

Warren, can I take this back step by step and see which bits you hate, and which bits you are ok with?

So, I think my original aspirations for this change were as follow:

1) I wanted a way to distinguish clearly between the desks 'automatic' mark cues and my designated mark cues
2) Once an automatic mark cue had been created, I didn't want that to be a valid choice for subsequent Mark commands. (One of the problems with the original behaviour was that the desk would create an automatic M cue to fix a single channel, but over time you'd end up inadvertently marking half the rig into it!)

So Warren, my first question is do you have a problem with either of these aspirations? If you do, then I fear we will need two different features, because I'm pretty adamant on those two.
However, if you can live with (or even support!) those two aspirations then I think what we're arguing about is implementation, and I'm much more flexible on that.

Assuming for a moment that we could agree on the above, I guess we'd then be looking at two questions:

1) Where should the emergency Mark happen in the cue stack? (this is the issue Nick touched on)
2) How should the emergency Mark be indicated?

Warren, I'm guessing that part of your objection is that the emergency mark happens immediately prior to the R cue? This isn't surprising given that its leveraging the existing broken mark functionality, but I could certainly agree that it would be nicer if it moved earlier rather than later (I actually feel that way about broken mark functionality and automark as well - but I'm definitely not brave enough to suggest that!)

With regard to indicating the emergency mark, I'm easy on this, provided that it doesn't display as a standard 'M' (so that we can distinguish the automatic mark cues, and they aren't subsequently used by the desk to mark other units as well, as explained above). I'm perfectly happy with the broken mark indicator ('x') but it could be pretty much anything as far as I'm concerned! Warren, would you prefer it if it was something completely different?

Andi.

P.S. Warren, you mentioned the Marking Priority discussion - and I'm not ignoring that comment deliberately, in fact I'm a huge fan of that idea! However, although that function would be intimately linked to this issue, I feel like w we would still need agreement on this particular issue - so for the moment I'm trying to stay on target to figure out this specific issue!

Hi All,

I was very much in agreement with Andi when we discussed this change a while back. It was originally intended for 2.3 I believe but slipped into 2.3.2 along with a few other in theory minor changes which didn't make the cut. That said, I can see how this could have a significant effect on your work flow if you were relying on the old behaviour.

Like Nick I had pretty much given up on using Mark Earliest M (I've never used Mark Earliest) precisely because the old behaviour was unpredictable. If I go to the trouble of creating Mark Cues it's precisely because I want those points to be the only points a unit can mark.

I have a feeling that this is one of those situations where we need 2 options because I can see the utility of both.

Warren - as far as your macro goes, I don't think that's related to this change. I think there were some changes to how marking was handled in parts which might be the cause of this.

Cheers

Dan

Hi All,

I was very much in agreement with Andi when we discussed this change a while back. It was originally intended for 2.3 I believe but slipped into 2.3.2 along with a few other in theory minor changes which didn't make the cut. That said, I can see how this could have a significant effect on your work flow if you were relying on the old behaviour.

Like Nick I had pretty much given up on using Mark Earliest M (I've never used Mark Earliest) precisely because the old behaviour was unpredictable. If I go to the trouble of creating Mark Cues it's precisely because I want those points to be the only points a unit can mark.

I have a feeling that this is one of those situations where we need 2 options because I can see the utility of both.

Warren - as far as your macro goes, I don't think that's related to this change. I think there were some changes to how marking was handled in parts which might be the cause of this.

Cheers

Dan