• Date
    warrenl
  • Date
  • Replies 17 replies
  • Subscribers 186 subscribers
  • Views 18612 views
  • Users 0 members are here

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

Parents
  • 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.
  • in reply to Jay

    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!

  • in reply to Nick Simmons
    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!
  • in reply to Andi.Davis

    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

  • in reply to Andi.Davis

    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.

  • in reply to warrenl
    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.
  • in reply to Andi.Davis
    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
  • in reply to 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!
  • in reply to warrenl
    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.
  • in reply to Nick Simmons
    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
  • in reply to 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.
  • in reply to Jay
    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.
  • in reply to Andi.Davis

    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;-)

  • in reply to Nick Simmons

    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

  • in reply to Anne Valentino

    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

Reply
  • in reply to Anne Valentino

    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

Children
No Data
Related

www.etcconnect.com