Elements with extremely large manual adjustments should have autoplace disabled on import
Reported version
3.3
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
I have no doubt that the new algorithm for automatic placement in v.3 is an improvement, but for files created under v.2, it always creates problems, since my carefully placed text blocks and such are now automatically placed when I open them i v.3. I've now made a habit of (a) declining any suggestions to reset positions, and (b) select all text blocks etc. and untick the "Automatic placement" box. It's a tedious job, though, and since the algorithms are clearly incompatible between v.2 and 3, this should probably be the default behaviour when opening v.2 files in v.3.
Comments
Not everyone uses many explicitly placed text frames. Do you encounter problems even if you decline the request and set all boxes to non-auto placement?
In reply to Not everyone uses many… by Howard-C
Yes. My experience is that allowing auto-placement in that box gives even worse results than declining it. I attach two examples, one with "Yes", the other with "No".
Granted, the way I use text boxes in these cases is perhaps not very common, but (a) the behaviour is unpredictable, and (b) I can't really see any reason for it, that is: for automatically repositioning items that have been positioned specifically.
In reply to Yes. My experience is that… by eyolf
That "No" one seems fine to me. I don't know what do these "S D 6 5" mean, but the "B T d-moll" ones are OK?
Sorry, I forgot to attach the desired layout. I can remedy it/work around it by selecting all similar elements and unchecking the automatic placement box in the Inspector. But there are many files like this, and it's a bit of a chore. And, as I said: it should be an unnecessary one.
(I should say: these are assignments in music theory, where usually only the soprano is given, at times not even that, and the S65, D etc. are Riemann theory notation. MuseScore is now, I'm proud to say, the preferred typesetting application at the music department at Uppsala University, but this was almost a show-stopper.)
I fear many of us depend on that automatic placement feature, me included. If there is indeed a workable workaround, may it's best to keep the present.
I suggest that if you have a lot of customization in a version 2 score, keep it in version 2 for display purposes. If you want to hear it with version 3 playback, then open it in version 3 and don't get too worried about display. You can run versions 2 & 3 at the same time with no problems. Use version 3 for new scores so you can optimize the display and take advantage of the new features.
In reply to I fear many of us depend on… by Howard-C
I like the way automatic placement works in v.3 - coming from Lilypond, I'm all for sane, wise, aesthetically pleasing defaults - my issue is with unnecessarily overriding explicit, manual information made in v.2 when converting to v.3. So: are there situations where it is actually beneficial to set explicit score entries in v.2 aside?
In reply to I suggest that if you have a… by mike320
Mike: this is not really about my own needs in my own scores, but about the complete mess that my students experience when they open a file made in v.2. I can explain to them how to restore the placements, but as long as I can't really see any benefit from overriding manual input, it seems like a bad idea.
The majority of scores will see no obvious changes, just subtle improvements. A few that employed extensive manual positioning may indeed have issues. In order to investigate what room for improvement there might be for your specific score, we would need you to attach the actual score, not just pictures. In general, we do try to preserve manual adjustments when you choose "no" to the reset, but it appears that a handful of these got reset anyhow, for reasons we cannot know without the file.
But to answer your question, in fact there are a great many cases - the majority, I suspect - where answering yes gives better results. That's because many such adjustments were originally made to work around the lack of autoplace in MuseScore 2. Manual collision avoidance. Those adjustments now end up being unnecessary and often counterproductive, since they may be applied relative to defaults that start out correct.
The main problem is handling every customization made in version 2. There's not really, currently, a calculation that says the item is X distance above/below and Y distance beside the default location made during import. Basically this is because the version 3 placement algorithm is not an extension of version 2's but a replacement. It would be quite cumbersome to put the version 2 placement algorithm into version 3.
I understand your situation, you've created exercise in version 2 and don't want to go back and change them for version 3 because it's time consuming and also version 2 scores will open in both versions 2 & 3 if a student hasn't upgraded for some reason, like they still run XP.
In reply to The majority of scores will… by Marc Sabatella
This should be the original v.2 file.
fixing cross post with Marc.
OK, I see now why this particular didn't work so well, it's that the texts at the beginning of each system are actually attached to the staff above, and then dragged not only below that staff but below the bottom staff as well. This was a very unfortunate choice; was really done this way consistently? We already detect elements moved to the wrong side of the staff they are actually attached to, and we adjust the placement for those so they layout correctly, but we don't also accommodate ones move all the next to the other side of the next staff, as these were.
Except for those few texts, everything else in this file came through pretty well. But autoplace here is trying to create extra room between the staves to accommodate the texts moved across staves. Disabling autoplace does indeed workaround that. So would setting the "Min vertical distance" in Format / Style / Score to a large negative value.
Meanwhile, something we could consider is placing a cap on how much manual adjustment we'll try to accommodate before we decide to disable autoplace for that element. So for instance, if you answer "no" to the reset, elements with a manual adjustment of more than, say, 10sp - enough to move them to another staff (or measure) entirely - would have autoplace disabled.
In reply to The main problem is handling… by mike320
mike: that v.2 doesn't have an algorithm to handle placement is one thing, but surely it has the data available to handle the placement. So: somewhere in a v.2 file there is information to say: "place this text block 28.45 mm below the note to which it is attached", regardless of the algorithm that goes into each of the versions? So: the information is there, and the information that there is specific information is also there, and the fact that I can, with a couple of clicks, albeit for every one of the files, recover the desired placement - all of this tells me that the conversion from v.2 to v.3 could be made better.
And concerning your final remark: it's not about whatever effort I will have to put in in the conversion from one version to the next, it is about unnecessary problems, and - ultimately - about making MS an obvious choice for music departments and other institutions, which in some way or another depend on feature stability.
In reply to (No subject) by Marc Sabatella
No, these are not "extremely large manual adjustments" - as far as I have noticed, it applies to any manual adjustments.
Those are very large adjustments - check again. Click the "B:" in the first measure, for example, and hit Ctrl+R - now you'll see where that text really was attached, and how far you in fact moved it.
As I said, the key indicators at the start of each system are actually attached to the top staff and then dragged all the way not just below that staff, but clear below the bottom staff as well. So they are basically attached to the wrong staff than dragged a very long way to look like they are attached to a totally different staff. And that's the source of the problem, as I explained above, Ordinary manual adjustments - one that arne't used to move a text clear over to a completely different staff - are handled much better. The problem in this case is as I already explained: MuseScore is successfully understanding you want to move the text below the top staff, but it's not getting that you actually want it moved all the way below the next staff too, so it's adding space between the staves to avoid the collision with that staff.
What you did here is extremely rare, which is why no one has reported this particular case in the year or so since MuseScore 3 came out. Certainly there are other cases where it can be better to leave a MuseScore 2 file in MuseScore 2, but most examples of manual adjustment don't do this poorly. It's only because it was such an unexpected & extreme case that problems ensued here.