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

Hi Warren, hope you're well? :-)

Um, so this is at least a little bit my fault. Sufficiently so that I've been tempted out of forum retirement to post a guilty reply!

Obviously your description of the behaviour change is bang on the money - the issue here is whether the previous behaviour (i.e. the console automatically creating mark cues of its own accord when required) was useful/clever or disruptive. You clearly feel it was helpful (which I can understand) but I personally found it disruptive.

Now, I totally appreciate that I'm unlikely to persuade you to feel differently about that! But let me just explain what it is that I find disruptive, and why I think that makes this the appropriate behaviour for Mark Earliest M....

I am a bit of a control freak about my marking. To be honest, that's an understatement - its probably a legacy of my days at the RSC where, surround by acousticians and rig-noise obsessives, things moving in unanticipated places was a cardinal sin! So I am very, very keen on being the only person who makes decisions about where things move. And if the console is going to make those decisions for me under certain circumstances (as it sometimes has to to keep me out of trouble) then I want it to do that using a framework that is clearly separate from my carefully considered marking structure. That's why the console now ties into the broken mark behaviour - it still provides a safety net, but it does so without making alterations to the marking structure itself.

Now I fully appreciate that you will already have pondered all that, and so its highly unlikely that you're going to be persuaded! But the one thing I would say is this...

When Mark Earliest M was introduced, the specific reason for doing so was to cater for those people and markets that required really strict control over where things marked, and for whom Mark Earliest just wasn't a viable solution. So even if you fundamentally feel that the revised behaviour is unhelpful for your work flow (and obviously you are in a far better position than I to judge that! :-) ) I would never-the-less contend that a feature primarily aimed at people with very carefully devised marking structures should not automatically modify that structure when the going gets tough. And where it does have to take preventative action, it should do so in a way that is utterly transparent and does not impact on the underlying structure.

On the plus side (stand by for a desperate attempt to pour oil on troubled waters!) I believe we have now fixed it so that Mark Earliest M will find and use existing M cues where the unit is fading out, which it didn't previously. And my hope was/is that this should significantly reduce instances of the emergency behaviour we're discussing being required...

Andi.

Hi Andi!

Very well thank you...apart from being particularly grumpy about all the additional "x's" appearing on my screens and the doubling of my tidy up time! Which currently I'm holding you ENTIRELY responsible for in lieu of anyone else claiming responsibility so far!

Let me start by saying that I can completely understand your logic, I appreciate that it's not what necessarily was intended behaviour originally when Earliest M was introduced, but yes, I did find it a useful 'feature', particularly having worked with the old rules for so long already. I also think sneaking this big a change into a bug update release of software is a little cheeky without rigorous Beta testing (although I admit I got very little time to Beta test any of 2.3.1 or 2.3.2, so it might have been in for a few months)!

However, rather than just moan and whinge, I would like to suggest a couple of productive alternatives to a permanent rule change, which removes an old feature permanently. (Hey...I still mourn the loss of the Swap key/function on the Ion, I have gotten over it in time, but I can still see a purpose for it!).

I can't believe that I'm the only person that is missing the 'old' style rules, so my suggestion would be either:

Adding a new Mark softkey of "Mark Earliest M Only" (maybe too long to fit in a button but hey...different discussion!) which would follow your rules...this is a simple temporary solution to please me AND you quickly which won't require too much coding...

OR...and this would be my preferred option long term...that it would follow the rules of Mark Earliest when it can't find a defined Mark Cue, BUT, would place a different Flag in the Mark column...maybe a Red 'M'...this would follow the desk logic of "you need to make this your own" red values, and would clear when you place that Mark into a separate Part or move the Mark point in the Reference Cue...I realise this causes issues when there is a Reference Flag in the column that a Red M is placed in (maybe a Red M in the MV column would be a solution, although technically it's not a move and would also have potential '+' instances?)...but there must be a solution we can come to along these lines. Perhaps a '?' in the M column...again, this will probably be as long a discussion as Update Modifier titles was all those years ago!

My main argument is that, when us 'grown ups' use Referenced Mark, surely we rarely want a light to Mark in the cue before it's active, unless there is really no other option (which is the default rule that the broken Mark is currently following, in a slightly smug "don't worry love, I've got your back" kind of way). EVEN in a rehearsal situation before getting to tidying up, I don't want this to happen, and an X is not the correct way to tell me that there is no available Mark Cue early enough.

Maybe it could be claimed as 'lazy programming' to use my methods...but I've found it to be a great, speedy, catch-all way of marking (especially in the frantic musical tech sessions that I frequently find myself in), and I suggest that actually I AM ACTIVELY telling the lights to Mark when I use this syntax, and for the desk to essentially tell me off by placing an X in the Mark Column is frankly insulting! I always go back and tidy up my Marks into Parts...so I can normally spot when they are in a 'bad' place and adjust them afterwards, with my suggested "I've made this new Mark for you" Flag, it would be EVEN EASIER to spot when there might be an issue, and the console would have already suggested a nice 'early' place that it could Mark already, double win for the super-anal and the lazy!

I do know that there is ongoing conversations about Priority Marking which would bring a great granularity of all of this, but feel this would have been the time to Beta test THIS new rule change.

So yes, you're highly unlikely to convince me of the new rules! I have been using the desk, like you, since before we even got Mark Earliest, so when Mark Earliest M was introduced, it made my 'new found Mark Earliest' methods that much cleaner, easier and tidier, it was a step forwards...I just don't think we should step backwards 6 years later...let's move forwards again and expand the tools.

Does this make any sense or am I alone, on a particularly high horse, in need of a ladder?!

I now make a strong plea that this gets restored to the old rule, or resolved in one of my suggestions (or someone else's idea that I personally have entirely approved of) really quickly!

Sincerely,
slightly grumpily (currently stuck in Leicester, which makes me more grumpy),
but with love,

Warren.

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 and particularly Andi!

I'm a little less grumpy now and can probably make a little more sense in my responses!

I think we are actually all in agreement on this topic, it's just the way it's currently been implemented, which is a little bit rushed and not particularly using the capabilities of the desk.

I wholly, 100% and fully agree with both of your 'aspirations' Andi...

1- There definitely should be a way to distinguish between our own created Marks and an 'emergency placed' Mark. I like the idea you mentioned outside of this forum of an 'M' underscored - but I think as we have the luxury of coloured monitors (note the U in colour!), that we could make this even clearer to spot when scanning a Cue List.

2 - I think that once that automated Mark has been placed, it should be ignored whenever possible until we've manipulated or confirmed it in some way. I personally, and I'm sure MANY others do, alway put Marks into a Part, I think that as soon as we do this, that should become a defined Mark point and therefore available to Earliest M rules. (This then leads to the future priority marking conversation, but for now we only have the one option!).

My main issue is two-fold:

- that the Emergency Mark is being placed on the cue before the Reference, when before it placed it at an Earliest point (i.e. the cue after the unit faded out), but just didn't actually show us that it was NOT a pre-defined point. This is still likely going to be my preferred place to Mark...not in the cue before it's coming on...I work on too many fast cued shows to ever really want that to be the default action. I also work on too many shows with Tungsten moving lights, so wouldn't necessarily want to Mark in the same cue it's going out in...

- that the Emergency Mark is showing as a Broken Mark 'x' - I don't think this is correct and if it was to follow what we've discussed so far, a CLEARLY identifiable Flag to show it's an automatically placed Emergency Mark, then I'd be happy, I just don't like the desk telling me off for something I've technically already told it to sort out!

I'm a big advocate of the Flag columns and use them to show me where I have potential issues and places to tidy up. So I just think there needs to be distinction between a REAL Broken Mark and an automatically placed Mark.

Finally, for my Part 20 Macro, the ONLY reason my Macro doesn't work is because there is an 'x' on Part 1 - part of the macro says "Part 1 Mark" to remove the legacy 'm' that always remains after moving a Mark to a new Part. I've never really understood why there is always a legacy 'm', as we currently can only Mark in one part of a cue - but there's a different discussion!

So I do think we are actually all in agreement here and ultimately I don't think there is a need for 2 separate definitions, I just think it needs to work in a tidier way, and that it's been implemented in a bit of an untidy rush.

So we do all need to agree on the answer to Andi's 2 questions...and my preferences/suggestions would be...

1) Where should the emergency Mark happen in the cue stack? - the cue after the unit fades out, following the logic of Earliest
2) How should the emergency Mark be indicated? - a coloured underscored M - but I'm very open to this, as long it's clearly distinguishable.

I would like to say, that I totally understand the new behaviour, I can see the virtues, and utilise them too, I LOVE that it does now actually Mark in the earliest Mark cue, even if the unit is fading out in that cue...this is definitely a step forwards!

Warren.

Thanks Warren! Fingers crossed we're moving towards a compromise here - which would be a jolly good thing!

Dan and Jay... I just wanted to post back to you both because you seemed to be really in favour of the current (new) implementation. Speaking personally, I feel like I would be more than happy to get behind a promised compromise as suggested by Warren. Do you both feel the same?

Andi.

I can get behind the light making in the earliest it can instead of the cue before. I think that should be the behavior unless the cue before is a Mark already.
As far as creating an m, I am still against the console making an m, ever for me. I think the light and cuelist should still show an x so I know that it hasn't picked a valid Mark and I still have to deal with it.

As for the priotity making situation, I think this will help all of this situation slightly in that we can marks on the transition that the Scrollers can Mark in, but then making internal marks that we can create emergency marks and/or quieter marks.

I think I'm not backing down on the console shouldn't ever create an m for me.
Thanks

Jay

I'm suggesting that there needs to be a distinction between a console placed Mark (what we've been calling Emergency Mark) and a Broken Mark, which I would argue are essentially 2 different things.

In my head, a Broken Mark 'x' should only appear in my Flag column when I've gone back and used a light somewhere between it's original Mark and Reference. This is still a very useful indication, and I would argue, would be more confusing if we couldn't distinguish if it was genuinely something Broken or was an Emergency Mark placer (i.e. if they were both x's). In this instance I would also suggest that Broken Marks (in this context) should remain in the cue before the Reference, so that it is easy to locate where the Mark is broken from!
So I stand that we need something that is not an M, or an X, but that shows a 'useful Mark place' when the Earliest M is unavailable, but is never referenced until it is actively placed as a Mark Cue.

It also needs to somehow be visible OVER a reference 'R'...ie no '+' in the M column! perhaps something like a box appearing in the M column, that if populated with an R already, will surround the R?

Round and round we go! I'm convinced that we can make this work for everyone in a nice clean way!

The problem with Mark is you ask 20 programmers what the rules for marking should be and you'll get 20 different set of rules. Keep talking to the same programmers for long enough you'll have 40+ sets of rules.

The console places Marks if you use Mark Earliest as well, these haven't been emergency marks but console placed true mark points. The 'bug' which people didn't like was if they used Earliest M and the console couldn't find an 'M' for some channels it would just use the rules for Mark Earliest for those channels.

Dan Duffy could easily make rules for to all these problems but again I go back to the top comment, you ask 20 people what those rules should be and you'll get 20 different sets.

Personally I'll like Sir Duffy's mark coding time spent on Priority Marks and marking in multiple parts within a single cue.

Here, here, Nick. I agree. We will have to revisit this Story again in a year, when the code for priority gets worked out, which I believe will fix done of our problems, but will add more opinions when we sort it out.

Wise words, Nick.

Jay

Hi chaps,

Ha, I don't disagree - and there's an argument to say that perhaps we shouldn't have tried to sneak this one in, and waited to do it at the same time as implementing Mark Priority.

However, we didn't do that! And currently we have made a change that some of us love (Jay - that's you and me!) but others hate (Warren is not alone in this). So I'm trying to figure out a compromise of some kind that will provide a half way house to keep everyone reasonably happy until such time as we can visit the whole thing in a more comprehensive way.

Nick, I totally appreciate how precious Crown Prince Dan's time is - but I feel like I've basically instigated something that inadvertently screwed some people over. And I'm trying to help fix that! :-)

Andi.

And just to be clear I feel for Warren he has lost a function he was using which other people thought was a bug. And that has impacted his work flow.

I don't like or use any of the Earliest functions. I also don't like the convention of using Part 20's for all Mark's, I do but I don't like it and I've had to bow to the way other people work to make it easier on the people pressing Go each night.

Andi.Davis said:

Nick, I totally appreciate how precious Crown Prince Dan's time is - but I feel like I've basically instigated something that inadvertently screwed some people over. And I'm trying to help fix that! :-)

Andi.

Well I think you should feel guilty because you've completely screwed Warren over and if I was him you would have had a brick through the window by now!

With great power comes great responsibility!

I only wish over the last 8 years I could have got a change to mark in the software but DD just ignores me and I know he loves working on Mark code nearly as much as effect code;-)