Add options to fix anchor points for various elements such as rehearsal maarks
This is in response to discusson:
https://musescore.org/en/node/122411#comment-556666
which is in turn in response to bug 63856
The upshot of that change was to change the default positioning of rehearsal marks for some users despite there being custom templates loaded with various attributes altered including some attributes of rehearsal marks.
I would like there to be a way of locking a template applied to a score or part such that no future change in musescore that affects default positioning or attributes of an element necessitate the re-editing of a score to counter such changes.
I envisage a global lock attribute applying to an entire template to imply that each of the settings at the time to lock was selected would be equivalent to specifying every attribute of every element manually.
If that's too difficult to achieve, then a more granular version of this to apply per attribute.
And if that's still too difficult to implement the to apply to selected attributes where it is possible to implement.
Richard
Comments
Hmm, that's sort of a different requesn than what the title of the thread suggests. We could conceivably address one without the addressing the other. In general, expecting *no* future change in MuseScore to affect layout is just not reasonable, We do go to considerable trouble to avoid unnecessarily affecting older scores with most improvements we make to layout, but sometimes the changes are just too major. I would say we probably erred in allowing this change for a minor release like 2.0.3, but it's nothing compared to the sort of layout changes that necessarily occurred between 1.3 and 2.0 or that you can expect with 3.0. MuseScore is just too big, too complex already for us to be able maintain that sort of compatibility forever (which basically requires each version of MuseScore to duplicate most of the layout code from older versions as well as any new layout code, and requires future generations to have to continue to maintain all versions as internal representations change, etc).
So to summarize that point, we already *do* try to minimze impact of changes on existing scores between *minor* releases; this one case was just misjudged, I would say.
Totally separate from any of this would to add an option to allow the user to select the anchor point for text like rehearsal marks - aligned with the note (segment, to use the internal technical term) it is attached to, with the left barline, with the right barline, etc. That much is certainly doable and would probably actually *simplify* the code, because right now we make those decisions based on all sorts of special cases rather than simply looking at a flag in the text properties.
In reply to Hmm, that's sort of a by Marc Sabatella
Make of it what you can. I have to put stake in the group for backward compatibility where reasonable. Actually, I must say I don't fully appreciate the problem you were trying to address, particular as the solution look ungainly when applied to my scores.
Having said that, I would much rather more important features such as support for the block notation multi-bar rests were prioritised ahead of any attempt to redress what's now been done.
One of these days, when I am retired from being a s/w developer, I'll be able to help out. Until then I have to rely on the community. So do what you feel you can.
Richard
In reply to Make of it what you can. I by richardm999
The probloem we were trying to address was conforming to *other* scores, that do indeed place rehearsal marks after the clef/key/time signatures. This is the usual standard, and we were not obeying it, so this is what is improved - it adheres to the standard, and avoids the collision that otherwise would exist between the rehearsal marks and measure numbers. It just happens that the new position creates collisions if there also happens to be other text in that position. There is no getting around the fact that collisions will sometimes exist so users will sometimes need to resolve them manually, it was just a matter of deciding *which* collisions should require manual adjustment, at least until automatic collision avoidance is implemented for these elements types.
In reply to The probloem we were trying by Marc Sabatella
OK, I see that, but why were my marks subject to change given that I had customized their positions already? I think you did say that any customized marks shouldn't ave been altered.
In reply to OK, I see that, but why were by richardm999
Unfortunately I no longer have easy access to older versions to compare, nor I remember the exact comment you refer to. I do kind of remember saying something like that, but it is possible I misspoke. Or perhaps my comment applied only to certain manual adjustments (eg, adjustments made via the inspector as opposed to via styles or via properties), or only to certain alignments (left versus center versus right).
In reply to Unfortunately I no longer by Marc Sabatella
This? https://musescore.org/en/node/63856#comment-402356
In reply to This? by Isaac Weiss
Aha, yes. This suggests that it manual adjustments - eg, dragging, nudging with keyboard, or using Inspector - should be preserved (which is to say, the actual distance from the note they are attached to is what gets stored in the score). But changes made to the text *style* or text *properties* are stored differently; these would be relative to the default position of the rehearsal mark, and since the default position has changed, then changes made this way will not be preserved.
Maybe someonbe could test this? Create a score in 2.0.2 (or 2.0.1, or 2.0), add a rehearsal mark to measure 1, note that it appears all the way to the left (before the clef), then drag it to, say, between the clef and time signature 9above the key signature if there is one). Save the score, then load it into 2.0.3. I'm thinking you'll see the rehearsal mark still positioned where you put it, but if you then click it and press Ctrl+R to reset the position, it will reset to the *new* default, which is to the right of the time signature. Whereas if instead of manually adjusting the mark in 2.0.2/2.0.1/2.0, you had affected its position via text style or properties, you'd see that adjustment applied to the *new* default and thus the position would not be the same as it was.
In reply to Aha, yes. This suggests that by Marc Sabatella
If I can get Ubuntu to install two versions of musescore side by side then I can test it. I suspect I will need to download the source and build musescore outside of synaptic. Let me poke around on the website.