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.

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.