Layout of 1.3 scores
We need to decide how to handle 1.3 scores loaded into 2.0. So much has changed regarding layout that there is little chance 1.3 scores will look exactly the same when loaded into 2.0. In particular, there may be different number of measure per system for the same layout / stretch / style settings (most likely 2.0 will fit fewer measure on some systems), and also manual positioning of notes/accidentals/ties will likely not be correct given new improved default positions.
My initial proposal is that we do the following:
1) Automatically reduce stretch and/or minNoteDistance for 1.3 scores from what was specified, by maybe 5-10%, in hopes of fitting the same number of measures per system as before. If a score had explicit breaks, this should work well. If it didn't, then we might fit "too many" measures per system. But maybe that's OK. We could also consider only doing the automatic adjustment for scores that actually *have* explicit breaks.
2) Strip away all manual positioning from notes, chords, accidentals, and ties - also any user mirroring - and hope the new defaults render those adjustments unnecessary. We might want to put up a dialog on import (or have a preference setting) to say whether this should be done or not.
But we should do a bit more investigation - checking a representative sample of scores to see what differences actually exist - before deciding on a course of action.
Comments
One other consideration for loading scores, esp scores not your own, is having the correct page size. Now that the correct page size is detected for the user location, should that be compared to the score setting and changed if possible? I know this won't work for scores on large pages (i.e. orchestral, tall scores), but loading an A4 into letter (and vice cersa) won't print properly, and it's not the most obvious of settings to correct. Of course, this will open up a whole can of problems with score adjustments when changing page size.
I don't think paper size is one of the things that need adjustment, saved in A4 was most likely a deliberate decision, so it means it should stay in A4.
Honoring breaks is essential though.
Don't get too Euro-centric in your thinking. Here across the ocean we've had to consciously remember to change the paper size from A4 every time a score was made. And using a score from someone else does mean remembering to change the page size as well. Some pop-up warning you, or some auto-magic way of doing so would be helpful.
I don't think I'd favor changing the paper size stored in a score. That has an effect on layout - number of measures per system, number of systems per page - that many times won't be good. At most, a dialog warning if a score has the "wrong" paper size could be put up, either on load or on print. I suspect that prove unnecessary and annoying more often than not.
But this has nothing to do with 1.3 scores that I can tell - it's as much an issue opening someone else's score created in 2.0 as it is 1.3. I guess the one way in which ithis is 1.3-related is that for 1.3, many North American users were inadvertently creating A4 scores because they didn't realize they needed to change the default paper size manually. It appears this won't be an issue any more for 2.0 (!), but I guess we *could* make it so the dialog only appeared for users whose default paper size is Letter when opening a 1.3 score with paper size set to A4. That should cover the cases where you might *want* an auto-correct.
But I'm not very enthusiastic about any of this. North American users would get bad results printing A4 scores in 1.3 too. I'm not particularly interested in *changing* the results you get when loading/printing a 1.3 score versus what they would have been in 1.3. I'm just trying to *preserve* what you would have gotten, to the extent that makes sense.
It's not about being euro centric, I just don't want my scores to change their carefully crafted layout.
Hmm. but I would open them on the same PC, same locale, same default paper size, so maybe you're right and may there's no conflict?
see PR #889
I'll be fixing the automated tests soon, and adding another tweak to improve things further. So far in my own tests, the method I am using works pretty well.
1.3 scores in which users had not made any manual layout adjustments should simply look better due to the general layout improvements in 2.0, and I do now compress the spacing slightly on import to increase the likelihood of keeping the same number of measures per line (although this remains a crapshoot; a select all / reduce stretch sequence may still be advisable in some cases).
Layout adjustments made to work around the outright bugs in 1.3 layout (short ties, plus seconds, accidentals, and dot and articulation placement in multi-voice contexts) are no longer needed and in fact would no longer work correctly due to the numerous changes in default position of various elements. But with the manual adjustments stripped off automatically in 2.0, everything should look as good or better than it did in 1.3 even with the manual adjustments.
Layout adjustments made for other reasons are more problematic. These also would not necessarily have worked correctly in 2.0, so something needed to be done, but it will mean user intervention will be required to re-apply the corresponding adjustments. In practice, the one case I ran into often enough to be concerned about was where the user had made manual adjustments to force unisons to overlap that normally would not have - between an eighth note and a half note, for example. But I think I can handle that specific case automatically by doing the overlap automatically if one notehead is hidden, as one would also have needed to do anyhow.
So after running dozens of scores through, I feel pretty good about where we'll be. Most users will see nothing but no change or automatic improvement. Only a scores with "unusual" use of manual positioning will require re-work. But it's enough of a concern that I agree with lasconic's suggestion (made elsewhere) that older scores be opened as "imported" scores, so a save operation will prompt for a new filename. That way there is less danger of inadvertently overwriting your 1.3 score and thus losing your original adjustments permanently.
My PR is merged, and it includes some pretty handling of unisons. So we're mostly there, and I welcome testing.
One thing I realized I missed has to do with ties; in certain cases older scores will miss some of the improvements there. I was too conservative when I initially made those improvements. That's a trivial fix I'll add shortly.
The other open question to me has to do with cases where the user has deliberately set a chord in voice 3 to be offset slightly from a chord in voice 1 (or voice 4 from voice 2). I am currently ignoring this along with other manual positioning. I would like to be able to preserve these offsets, but we would have to address #25648: Accidental does not move with manual adjustment to note/chord. That too is a very easy fix that I already made but then backed out after seeing Werner's comment. Still, I am not confident that the specific offsets a user applied in 1.3 would make sense in 2.0, especially if offsets had also been applied in other voices.
It *is* easy to select all notes in voice 3 and then use the Inspector to apply a constant offset to them all. Or I suppose a plugin could be written to detect actual conflicts (places where a voice 1 & 3 chord exist on same staff / same segment) and apply an offset if so. That's something that would benefit new scores as well. I *could* do this automatically during layout, but it's always the right thing to do, so I think requiring the user to make it happen manually is better.
BTW, I meant "it's *not* always the right thing to do" in the last sentence of my last post.
PR submitted to fix the tie import issue:
https://github.com/musescore/MuseScore/pull/903
As far as I am concerned, the only thing remaining for sure is to look at treating the load of a 1.3 score as an import - so you would be prompted for a new filename before saving.
At that point we could consider the issue closed and just submit specific bug reports for anything that doesn't import properly.
Marc, did default tie/slur positioning change between 1.3 and 2.0? Would removing the movement offset for tie/slur import (not the shape changes) also be good?
Yes, the tie positioning / sizing was actually the first significant change made - part by me a few months ago, part by someone else longer ago. See #2316: Small ties. But since my contribution to this was the first layout-related change I made, I was conservative and disabled one important aspect of my code for 1.3 scores. Then, after making all my other layout changes (including further tie improvements), I completely forgot that I had disabled a part of the tie improvements for 1.3.
The first PR I did for the current issue removes all manual formatting from single-segment ties in 1.3 scores - both positioning and shaping. That's because depending on the specific case, sometimes moving the tie vertically was all the workaround you needed in 1.3 to make the tie visible. Other times you'd have needed to use edit mode to reshape the tie (moving the endpoints horizontally or middle points vertically). But in any case, none of this should be necessary any more - the default shape and position should almost always be good. And even in the rare cases where it isn't (ties between clusters is the one I know about), the default positions are still different enough from 1.3 that the manual adjustments you made originally won't produce the expected results any more.
So again, my first PR removed all manual adjustments, leaving you with the defaults. But I forgot that one of the tie improvements had been disabled for 1.3 scores - so one aspect of the defaults was not going to be as good as it should be. All I've done now with the second PR is enable that improvement for 1.3 scores, so the defaults really are as good as they are supposed to be.
The reason I asked was because I have a complex file that was created back in 1.0. I did manual adjustments to almost everything to make it work, including slurs (not ties). Most of the note layout changes you've done now allows the note layout to work by default, no manual adjustments. However, this is not working for slurs. Any manual repositioning I did (not shape changes) are still being imported.
Yes, slur adjustments are still imported, and I don't see any reason why they shouldn't be. No significant changes were made to slur layout that I know of. Certainly I didn't make any. i think Werner might have made some changes, but nothing so extreme that manual adjustments made in 1.3 would be invalidated. Unless layout changed such that slurs that formerly fit on system now span two, or vice versa. Unfortunately, I can't think of a way to detect that.
I guess maybe the note layout changes could in a few instances affect whether or not a slur needs adjustment, such that it was previously necessary but isn't any longer? if that's what you mean, could you attach an example?
BTW, changes to the endpoints of a slur do count as shape changes as far as the code is concerned. That is, they are stored as adjutments to individual control points, not to the slurs or slursegment as a whole. Not sure if that's what you mean?
In this case I am only referring to offsets (horiz, vert movement) and not manual grip adjustments. Manual offsets in 1.3 can get somewhat amplified when imported into 2.0 and so it seemed possibly advantageous to remove only those offsets.
Could you post an example? I'm trying to get a sense of the specific cases where stripping off these offsets would make sense.
I only have my file, I will include it. I don't recall why I changed the position and/or shape of almost every slur, but I did. Now, when loaded into 2.0 the location away from the default position is larger than 1.3. It just seemed an easier solution to remove the manual repositioning during import to get slurs properly repositioned, esp those that might have changed because of note repositionings due to your code, than to have to select every slur and do Ctrl-r.
This is 2.0 showing a dragged slur.
![150.png]( "150.png")
This is the position of the same dragged slur in 1.3.
![151.png]( "151.png")
Because the default positioning in 1.3 is different from 2.0, it might be wise to remove the X/Y offset and let it go to default.
PS: This is the same score I've been using to watch the note positioning changes you've made. Because of the mixing of the two themes, large and small notes, flipped notes, and unison notes, I've managed to see some things that were missed. It's also my best test case to see if 2.0 can render it close to 1.3, and it's very close now!
OK, I see what you mean on this score. I can see that for a number of these slurs - especially the slurs in the downstem voice 2 notes - the default slur end points were not aligned with the ends of the stems, so you moved them. And for 2.0, it appears the default does align slur endspoints with ends of stems, so these adjustments no longer make sense. I do recall hearing Werner had made some slur improvements long ago, perhaps as part of the Goldberg project.
However, according to both the Inspector and the Debugger, the edited slurs I checked out *were* in fact truly edited and not just dragged - their start and end points had been changed, as opposed to the just the overall offset. So it would not be a question of throwing away overall offsets only - I'd have to reset the shape adjustments. And shape adjustments made for other reasons (like to increase the arc of a slur to avoid notes) are very often still good.
So before simply deciding to throw away all slur adjustments, I would like to understand the nature of the slur changes better. Maybe it would be possible to come up with a compromise - throw away only changes to overall offset (which was not the case for the slurs in your score I looked at) or edits that only affect end points but not interior control points.
BTW, you don't have to select the slurs one by one to reset them - just select them all all once (right click, select all similar).
I'm only concerned with moved slurs, not modified slurs, but if you think some middle ground can be reached, so be it. I did modify many of the slurs, but not all.
The bigger issue is that default slur positions did move between 1.3 and 2, and any user-modified change in position in 1.3 is being amplified in 2.0. This seems to be the case for many things like text, dynamics, slurs. By at least resetting the X/Y offset, the default position will be attained.
Let me be more clear: your slurs *were* modified; they are *not* simply moved. I think you probably moved the endpoint handles on a number of slurs and thought of that as simply a move, but it's not. If you look at the actual MSCX generated, you will see that every single one of them has o1, o2, o3, and/or o4 tags - the result of editing the slur (dragging individual control points). A couple have offset tags - the result of simply moving the slur without editing it - but only a few, and these invariably *also* have o1/o2/o3/o4 tags. So it really is not at all clear that simply removing the offset tags - the "moves" - would accomplish what you want here.
So that is why I am suggesting that maybe it would be possible to ignore edits to o1 & o4 (the endpoints) if there are no edits to o2 & o3, or something like that. As well as ignoring any actual moves - but again, your score contains very little of that. Your slurs are pretty much all edited.
I'm not sure what you mean about offsets being "amplified" though. As far as I know, the magnitude of the offsets is exactly the same as before - it's just being applied to a different starting point. That is indeed the problem I am trying to address here for the items where I understand the changes and know they really do result in better defaults. I'm just don't understand the change in slur defaults - if they really are better overall, or if perhaps it's just an accidental that they are different at all.
Same with text & dynamics. As far as I know, the magnitude of the offsets is honored, but the default position may have changed. It *shouldn't* have, though, as style parameters should be controlling these defaults. So again, if you have specific examples, I'd like to see them to understand what you are talking about.
I don't recall changing all the slurs, and honestly when you select them one by one, reset and watch them change position and shape, most of them just look like they were moved.
Regardless, you're missing the point. Here is the default position for a slur in 1.3
and here is the default for the same slur in 2.0
_Any_ manual move to a slur in 1.3 to make it look better, as I have done all through the score, will result in them being further out in 2.0. Hence why I think at least the offsets for slurs should be removed as the default in 2.0 is much better.
I suspect the actual effect of changing only the end points of a slur - assuming you change both of them by the exact same amount in both directions - would be indistinguishable from a move. That's why I am suggesting special-casing edits of endpoint only. They are "just moves" in actual effect, if not in mechanism.
Anyhow, I don't *think* I am missing the point. I definitely get that *in this particular instance*, the default position for the slur has changed for the better, and thus any position adjustments made - whether accomplished by a true "move" or by changing endpoints as you have done - may no longer make sense. And it is definitely cases like this that caused me to strip off manual adjustments to other elements. But for those elements - notes, ties, accidentals - I have a high degree of confidence that the new default positions are actually about as good as they can be, and I am also willing to bet that working around these particular issues is the main reason manual adjustments would have been applied to these elements in the first place.
What I don't have a good handle on is to what extent either of these things is true of slurs. That is, your example shows *one* particular bug in default positioning of slurs that has been fixed for 1.3. So slurs that were moved *in order to work around that one particular bug* no longer need manual positioning adjustments. But what about slurs that were moved to work around *other* issues that have *not* been fixed? Or slurs that were moved simply to avoid collisions with other elements? I am concerned that by stripping of manual position adjustments, we would be destroying perfectly good work.
Again, the difference here is that for notes, ties, and accidentals, I think I have a pretty good understanding of what has actually changed, and a pretty confidence that the current defaults are likely to be at least as good as whatever the user managed through manual adjustment. I just don't have nearly as good an understanding of what has changed for slurs, so I have no such confidence that the new defaults are good enough that we can safely ignore all manual positioning.
I'm certainly willing to be convinced, but right now, I just don't have enough context to make this determination. And until I do, the safer course would seem to be to let the user decide - keep the adjustments, but let you select all and either reset position (via the reset buttons in Inspector) or take a chance and do a full reset - Ctrl+R - which also undoes the edits (including endpoint edits like yours).
You're focusing too much on the specific case I used to show the differences. Check my sample score, do a Ctrl-R on the slurs and then see what special cases need adjusting. This score is a good test case, and yes there are some slurs where I did manually adjust all points to get around notes and stems.
Regardless, the default position for slurs has changed for the better and in order to utilize that one would need to either
1) manually correct all slurs one at a time
2) select all slurs, do a ctrl-r on all (removing both offset and shape change) and then fix the bad ones
3) have just the offsets removed and defaulted during import, retaining the shape.
I would certainly choose option 3, given the improvements made so far.
Ah, I think I see what you mean now. I was using the Inspector to view the slur data, and wondered why _so_ many had 0/0 offsets but were obviously not in the default position. So my "solution" would only work for truly dragged slurs, not the way I modded them, and that may not be many even for the average user.
Right. Your slurs do mostly have 0/0 offsets, but what they actually have are modified endpoints (o1 and o4 tags in the MSCX) file that has the same *effect* that a simple offset would. If it weren't for this fact, you would have a fourth option in your list above: select all, then use *Inspector* (not Ctrl+R) to reset just the offsets.
Now, it wouldn't be difficult to detect cases like yours - slurs where the user has modified o1 and/or o4 but not o2 or o3 - and treat those the same as slurs with offsets. Namely, by stripping off the adjustment. But it still makes me uneasy, because I really don't have a good sense of what other use cases would be affected.
You are right that your particular score makes a good test case, but realistically, what it shows me is the same basic issue over and over. You consistently have two voices on one staff, with separate slurs for each voice. This particular situation causes slurs that would otherwise have attached to the noteheads to instead attach to the stems, but in 1.3, they attach mid-stem rather than to the ends. So you needed to adjust a lot of the slurs, and this particular adjustment - this one type of adjustment you made over and over - is no longer needed or welcome, because the default *in this particular scenario* has been fixed. I really do get that.
However, that particular use case - two consistent separate voices on one staff with separate slurs for each voice - is not the only case to consider, and in fact, it's probably a pretty small minority of all slurs. Much music has only one voice per staff, and the slur attachment is completely different in those cases (it defaults to head-side rather than stem-side). And for piano music - which makes heavy use of multiple voices - it is not that common to have separate slurs for upper and lower voices. On the other hand, cross-voice slurs are much more common than they would be in your use case. So the particular issue you see over and over would not be seen at all by many or most users. On the other hand, they may well be seeing issues you are *not* seeing, and they might want to *keep* their manual adjustments, because the issues they were working around have *not* been fixed as yours has. That is, they may well disagree with your that the defaults have been improved, because they are dealing with different defaults because of their different usage.
So while you keep seeing the same 1.3 bug - bad attachment for stem-side slurs - over and over, I am still not at all convinced that this is very representative of other types of scores with slurs. And these other types scores with slurs may well have lots manual adjustments that should be preserved.
With the recent change to open older scores as "new", this completes everything I had in mind for this task.
The situation with slurs is still a little troublesome, but right now, I don't see a way to throw out adjustments only for slurs that were adjusted to workaround a bug that was fixed but keep ones that were made for "legitimate" reasons.
No doubt there are still a few other layout compatibility issues here and there, but I think at these point it is better to track those individually.
I am therefore closing this task, feel free to open new issues for specific incompatibilities.
Automatically closed -- issue fixed for 2 weeks with no activity.