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

With 2.3.2 we seem to have changed the rules on how Mark Earliest M treats a fixture that can't Mark in a previously flagged Cue (i.e. there is no Mark Cue available up stream after it was last used), where it now treats it as a broken Mark. For years it has always worked that if it couldn't follow the rule of Mark Earliest Mark, then it would follow the rules of Mark Earliest...which in my humble opinion, is EXACTLY what I want it to do!

Now that it places a broken Mark and follows the rules of a broken Mark, this causes no end of headaches! Firstly that it doesn't Mark at a nice early point and secondly that it needs a lot of tidying up, and finally that my quick Part 20 Macro now doesn't tidy up as nicely! As "Part 20 Mark (to move the Mark part), Part 1 Mark (to remove original Mark point) Part 20 Label etc etc etc...." in a Macro now places a '+' in Part 1 (if it has a Reference) or an 'm', rather than doing exactly the opposite.

I don't want to go back to using Mark Earliest...as this isn't what I want 99% of the time, so would like the desk to remain as clever as it was before!

What is the reasoning for this going away? It was such a useful feature and made for seriously quick programming on these ridiculous fast and cue heavy musicals! It now takes an age to tidy up and find what's occurred.

It's been a while since I was last behind the desk and not used 2.3.2 until this week...so only just found it, but judging by the release notes it came in on 2.3.2 as a 'feature'...I really don't think this is correct behaviour or indeed a 'feature'!

Warren

  • Thank you all for your input. I've heard directly from some of you and believe a suitable solution exclusive of priority marking can be reached.  While that will add a great  deal of control, we can't force people into using it.  And this solution needs to come with some dispatch. As such, if you don't mind - we will take this conversation off-line, have the further lively dialogue and then return with a proposal.

    Additionally, there are a few take-aways. Warren, I'm terribly sorry about the disruption to your workflow.  I knew it was bad when Bruno emailed me to help get his happy programmer back.  But I'm not sure I will be able to forgive you for putting the image of a smug broken mark indicator in my head. Each time I see it now, I'll surely think "cheeky bugger." And NICK! NICK. Honestly. Don't make me pull an SCR list of mark changes that had your name attached to them!! Finally, Andi! You graciously took one for the team here. We won't forget that anytime soon.

    More soon all. And again, thank you....

    Anne

  • As promised - the resolution. In 2.3.3 (which is now in beta if anyone is interested to have a play) will include a new setup option called "Emergency Mark". Since this is a new term for Eos, the help message will advise what an emergency mark is. This will contain two choices. Mark Earliest (which follows the conventions prior to 2.3.2) and Mark Latest (which follows the conventions of 2.3.2). The default will be Mark Latest.

    This behavior is ONLY called when Mark Earliest M is deployed and there is no M cue to mark to.


    Thanks again all.
    Anne

Related