Offset persistence: Align Spacing causes Nudge loss

[q]

 
The lack of 'offset persistence' is perhaps Encore's greatest shortcoming. In an instant, though a single use of Encore's Align Spacing function, an Encore user can lose every spacing refinement manually applied to a score. This can amount to hours of lost work, the need to revert the score, or restore the score from a backup.

I would like to see an option in Encore's Align Spacing dialog that preserves offset, positive or negative ... and not as a fixed value, but as a percentage of the available space. Presentation of this option might take the form of a check box entitled:Preserve manually applied offsets.


For a moment, let's use the term "normalized" to refer to the x properties (of various notes/objects) that Encore sets upon Align Spacing. (Even we have the option of choosing alignment styles available in the future, each option will produce it's normalized positioning.)

In this discussion I use the term "offset" to refer to the "x position" override that the user invokes by nudging (or by dragging a note.) An offset is the difference between where we put the note and where Encore would have put it? When nudging I'm ALWAYS OVERRIDING Encore's original sense of ideal or norm and thereby creating, or I'm updating an offset.
Because Encore lacks 'offset persistence' I cannot make large changes in a score (or perform ANY action that would invoke Align Spacing) because that causes Encore to reemploy its default spacing. When Encore reapplies it's default spacing it discards all of my meticulous refinements (i.e. it discards my careful improvements over Encore's limited "object spacing" intelligence.)

Any 'user-refined score' is a risk. (By 'user-refined score' I mean any score in which the user has carefully adjusted object placement beyond Encore's default placement. By 'risk' I mean that Encore may permanently discard some or all of the user's detailed decisions, rendering a perfected score (or portion of a score) back to default object placement, or it may badly dis-align it to some gangly intermediate, pre-aligned state.

According to Jef Raskin, in his book "Humane Interface", the primary goal in software development is to preserve the user's data. This means that Encore should preserve ALL offsets, until the user explicitly changes or deletes them.

I'm not under the illusion that anyone can create notation software that can foresee and fulfill the spacing requirements of every situation and for every user. That's precisely why we have the (nudge) option: to override Encore's spacing decisions. But we should be able to retain those decisions as long as we want, even after reinvoking Align Spacing. Align Spacing should know how to reincorporate user offsets, not just toss them aside.

Yes, I've express these sentiments previously on this forum, but cannot find the posts. In those discussions I suggested that Encore should also employ optional visual feedback (colorization?), so the user can see what objects are governed by user offsets. And Encore should offer a simple means for clearing ranges of offsets—for instance there could be a Clear User Offsets checkbox in Align Spacing (set of OFF by default!)

Persistence is hugely important! We've been waiting for a long time.

I hope Gvox development will prioritize this issue appropriately. I stand to loose data by the day, hour, and minute.

q

[q]

 
Please note. Aside from nudges, Encore may discard other offsets without user request, and without warning the user:

http://www.gvox.com/forum/viewtopic.php?f=10&t=3011&p=17782#p17445

Nice feature, if it had a name, a command name, and if it could be limited and focused.

q

[polarbreeze]

I'd like to see GVOX also paying more attention to making sure the default spacings are good. That would mean less customizing, and so less to lose with an auto-align...

[q]

I'd like to see GVOX also paying more attention to making sure the default spacings are good. That would mean less customizing

Yes, something seems to have gone amiss with spacing in the 5.05 Mac release. There's lots more object collisions with barlines, misalignment of accidentals, plus some overall crowding.

q

[q]

The lack of 'offset persistence' is perhaps Encore's greatest shortcoming. In an instant, though a single use of Encore's Align Spacing function, an Encore user can lose every spacing refinement manually applied to a score. This can amount to the loss of hours of work.

Because Encore lacks 'offset persistence' we cannot make large changes in a score (or perform ANY action that would invoke Align Spacing) because that causes Encore to reemploy its default spacing. When Encore reapplies it's default spacing it discards all of my meticulous refinements (i.e. it discards my careful improvements over Encore's limited "object spacing" intelligence.)

Any 'user-refined score' is at risk. (By 'user-refined score' I mean any score in which the user has carefully adjusted object placement beyond Encore's default placement. By 'risk' I mean that Encore may permanently discard some or all of the user's detailed decisions, rendering a perfected score (or portion of a score )back to default object placement, or badly un-aligned in in some gangly intermediate, pre-aligned state.

According to Jef Raskin, in his book "Humane Interface", the primary goal in software development is to preserve the user's data. This means that Encore should preserve ALL offsets, until the user explicitly changes or deletes them.

I agree that this is a very troublesome problem, which does need fixing. However, thinking of it as "preserving offsets" presupposes that Encore actually contains the concept of "offsets" in the first place.

I assume what's meant by "offset" is the relative position of an item: relative to the position which would be created by auto-align.

My hunch is that Encore does not presently have a concept of "offsets", but this is of little concern.

... AFAIK Encore only keeps track of the absolute position of the item: it doesn't retain any knowledge about how the item came to be in that place. So, in that sense, there is no "offset" value to be retained. For the same reason, I'm not sure that "colorization" (to identify items not in their default positions) is easily implemented.

Your statements imply that if Encore only knows absolute positioning—i.e. if it hasn't kept track of "offsets—then Encore cannot determine and store them in it's object model. If that is your thinking, I disagree. A determining mechanism largely exists within the Align Spacing function itself.

The creation and initialization of offsets would proceed like this:

1) Add an offset property to all align-able objects.

2) Have Encore run an "offset determining" mock Align Spacing function, but instead of moving the object to its "properly aligned x position", store that x value in mockAlignX:


if (targetObject.x <> mockAlignX)

{
targetObject.xOffset == targetObject.mockAlignX - targetObject.x
}
Result: Each alignable object now has an xOffset property that identifies the user's attenuation of its x property.

Hopefully Encore's current file format allows for the addition of a xOffset property. If not, then we'll have to wait until development updates the file format.

q

[polarbreeze]

Your statements imply that if Encore only knows absolute positioning—i.e. if it hasn't kept track of "offsets"—then Encore cannot determine and store them in it's object model. If that is your thinking, I disagree. A determining mechanism largely exists within the Align Spacing function itself.

Hmm, I think that's problematic. To determine the offsets after the fact it would have to "unscramble the egg" and figure out where everything would have been when aligned, which is essentially what your algorithm does. And to do that it would have to know whether said alignment was mathematical vs engraver, and whether it was "adjusted for lyrics" or not, etc. I really think it needs to work with absolute values, which then begs the question as to what happens if the measure width is changed (actually that's an issue either way).

I think it would be more fruitful to have a concept of "locking" the alignment rather than preserving offsets. This should be relatively easy to implement because it's like turning off autospace but only for a selected range of measures (or systems). It could include a simple rule if the measure widths change: just prorate all spacings in the measure.

[q]

Your statements imply that if Encore only knows absolute positioning—i.e. if it hasn't kept track of "offsets"—then Encore cannot determine and store them in it's object model. If that is your thinking, I disagree. A determining mechanism largely exists within the Align Spacing function itself.

Hmm, I think that's problematic. To determine the offsets after the fact it would have to "unscramble the egg" and figure out where everything would have been when aligned, which is essentially what your algorithm does. And to do that it would have to know whether said alignment was mathematical vs engraver, and whether it was "adjusted for lyrics" or not, etc. I really think it needs to work with absolute values, which then begs the question as to what happens if the measure width is changed (actually that's an issue either way).

Regarding mathematical vs engraver, and whether it was "adjusted for lyrics" or not, I would gladly answer a short survey and manually identify the whether Encore should calculate offsets relative to "mathematical vs engraver" (I always use engraver) and/or relative to "adjusted for lyrics" (which I rarely use, and only use for the very small number of my score that including lyrics are present.) It would be enormously easy for me to choose "engraver" and uncheck "Adjust for Lyrics" in a pre-calc survey. So again I think this is doable And it means Encore could bring offset intelligence to any legacy score—which may now include Encore 5 format.

And in the future, yes, each measure should carry a property that identifies the type of alignment last applied, including engraver, "adjust for lyrics" and "all staves".

I think it would be more fruitful to have a concept of "locking" the alignment rather than preserving offsets. This should be relatively easy to implement because it's like turning off autospace but only for a selected range of measures (or systems). It could include a simple rule if the measure widths change: just prorate all spacings in the measure.

I meant to mention earlier that you concept would be of much help, at least until this is all sorted out, because it would allow me to work safely without worrying about Encore discarding all my finishing touches.

Whatever the case, its' good to circulate some ideas around a very stale issue. Your input is much appreciated!

q

[polarbreeze]

...allow me to work safely without worrying about Encore discarding all my finishing touches.

Maybe it's worse than I thought - but I had assumed that provided you make sure auto-align is switched off nothing can get messed up. Is that not the case?

[q]

...allow me to work safely without worrying about Encore discarding all my finishing touches.

Maybe it's worse than I thought

I believe it is.

... I had assumed that provided you make sure auto-align is switched off nothing can get messed up. Is that not the case?

As far as I can tell everything can get messed up, and often does—even with Preferences>Auto Space off.

Personally I'm quite tired of the measure and score trouncing. I don't have time today to construct replication scenarios, but try searching the forum for "+extreme +gestures". Iindeed there are many less extreme actions that send ruinous ripples through a measure, line or score. The only automatic resort is Align Spacing, that then you lose all you nudged offsets.

q

[Andre]

When I perform an "align spacing", I'm not sure I want to preserve the manual alignment I did before. Why would I performa an "align spacing" then?

Now, I confess that I generally perform the manual alignment by dragging the notes and lyrics; and once some measures are ready, I avoid touching them again with align spacing (and, "undo" also exists, not to count érevert to saved").

I agree that "nudge" (right or left) could be different, and be seen as a "permanent offset". In that case the offset could be remembered with a note (I would say as a percentage of measure width). These offset would then be reapplied after an "align spacing".
I guess that an option of "align spacing" would then be to remove these offsets.

At first glance, I may want to have this applied only to "engraver spacing". If offsets would be rememberd by "mathematically correct", then it would no longer be mathematically correct.
I thought that an "align spacing" with MC would be the way to reset offsets (no need for an option), but I'll not insist on that since it would not allow the reset in the MusicTime subset.

[polarbreeze]

When I perform an "align spacing", I'm not sure I want to preserve the manual alignment I did before. Why would I perform an "align spacing" then?

I'm on the same page as you on that one Andre.

The issue seems to be that note (and object?) positions (whether regarded as "offsets" or as absolute positions) can be disturbed by operations other than align spacing. For example, changing the number of measures per system obviously changes the measure widths so Encore must decide how to position the notes even if auto-align is off.

In the past Encore has been prone to make errors in such decisions, which corrupted the note positions and often could not be undone - ie bugs. However, AFAIK this was all cleaned up in Encore Mac v5. I just took some time to double-check this and I find that, for example, increasing the measures per system (with auto-align off) does pro-rate the positions of all the objects in a measure (aka preserving the offsets). I can take that right up to an "unreasonable" number of measures per system, and back again, and all manual repositioning I had done is preserved perfectly.

So it's possible that this discussion relates to bugs that were already fixed (or largely so?) in Mac v5 - though I don't know if the same fixes have been applied to Win v5 yet.

[anaigeon]

I'm about to think that this problem is a quite general one.
Any user action overriding an automatism or a global change (i.e. stems directions) should get a special status leading, at least, to a question before the next automatic or global procedure procedure :
Keep previous user changes ?
No - Yes
This would just involve, for those properties, a "user has changed" bit which would be handled the same way as the the one handling the modification of a file.
Of course the number of such bits couldn't grow too much, but for the case discussed here, it would be fair enough that a measure where any spacing or nudging has been changed by the user would be protected against automatic spacing - unless the user answers No.
You have talked about that in more details than I could, but what I'd like to emphasize is that spacing isn't the only case in which we have this problem.

(BTW, some changes are more or less protected, for instance the tempo relationship between measures is respected when a global tempo change is made with the metronom).

[Andre]

Indeed, some behaviours must be regarded as bugs: let's say when they produce a wrong output rather than one which does not please us. The latters are subject to discussion for improvements, and I feel the discussion must suppose the bug corrected first.

Now, it may happen that bugs are better corrected by a design change: one is always better in knowing what the final goal is.


When the size of a measure is changed, one expects the contents to be expanded or compressed proportionally. The action must not depend on the setting of "autospace" (currently there is a bug in W502: when autospace if off, notes can be hidden of pushed into the following measure).

I always saw "Auto Space" as doing something only when notes are entered - and think it would be useful also when their duration is changed. Perhaps with a manual guess too.
But when notes are dragged or nudged, the spacing should not be altered.

[polarbreeze]

When the size of a measure is changed, one expects the contents to be expanded or compressed proportionally. The action must not depend on the setting of "autospace" (currently there is a bug in W502: when autospace if off, notes can be hidden of pushed into the following measure).

OK, let's work with that example. I think that when moving a barline (thus changing the widths of adjacent measures), the following is the desired behaviour:

1. If autospace is "on": the notes etc in the adjacent measures are repositioned according to the selected auto-spacing options, overriding any previous manual positioning. (To put it another way, yes, the "nudges" are lost - but surely that's the whole purpose of "align spacing": I'm not sure what other behaviour we can expect from it).

2. If autospace is "off": the notes etc in the adjacent measures are repositioned with all spacings pro-rated to the measure width, thus preserving (proportionally) any adjustments the user had previously made. (In particular, putting the barline back where it started necessarily restores all positions to where the user had previously put them, ie they persist: the "nudges" are not lost).

3. In both cases above, UNDO is available; however Encore keeps no record of the change beyond that.

Currently, behaviours #1 and #3 are as described AFAIK. However, behaviour #2 only happens if the change in barline position is a result of changes to the measures-per-system: if the barlines are changed manually, odd things happen - this is a bug. These comments apply to Mac v5: I'm not sure whether Win v5 behaviour is the same or different.

[Doug Kerr]

OK, let's work with that example. I think that when moving a barline (thus changing the widths of adjacent measures), the following is the desired behaviour:

1. If autospace is "on": the notes etc in the adjacent measures are repositioned according to the selected auto-spacing options, overriding any previous manual positioning. (To put it another way, yes, the "nudges" are lost - but surely that's the whole purpose of "align spacing": I'm not sure what other behaviour we can expect from it).

2. If autospace is "off": the notes etc in the adjacent measures are repositioned with all spacings pro-rated to the measure width, thus preserving (proportionally) any adjustments the user had previously made. (In particular, putting the barline back where it started necessarily restores all positions to where the user had previously put them, ie they persist: the "nudges" are not lost).

3. In both cases above, UNDO is available; however Encore keeps no record of the change beyond that.

I have purposely stayed out of this general discussion since the issues are broad and deep and I have not yet had a chance to think about it "top down", which of course ultimately is what it (like everything else we face here) needs. And I don't have the patience to figure out what "nudging" is and isn't. (It's a problem with a lot of "cute" terms.)

I may well be missing the significance of important specific issues, and I haven't followed the various tales of anguish (my apologies to the afflicted).

In any case, I tend to look for the clear and elegant solution rather than ones full of clever countermeasures for ill-thought-out basic behavior.

All that having been said, I am very attracted by the straightforward model presented here by polarbreeze.

Disclosure: I have spent about 5 hours today dealing with the bad human interface and misbehavior of a State Of Texas Web site whose ostensible purpose is to enroll me for concessions of about $215 on the purchase of a new high-end dishwasher we plan to buy (this is an "energy efficiency upgrade" program funded by federal stimulus funds). (In all fairness to the cognizant state office, the site was opened at 0700 this morning, and was soon receiving 1700 hits/second!)

And I just got up from a nap.

Bagel with cream cheese next. And I'll look up "nudging".

Best regards,

Doug