Bar shifts to previous system when any change is made to score
Open the attached score and use END to go straight to the end of the score. Keep your eye on bar 76. Now press Ctrl + A. The bar shifts position for no reason. In fact, any change you make to the score whatsoever, even to "score info", will cause the bar to shift to the previous system!
| Attachment | Size |
|---|---|
| bar_shifts_position.mscz | 52.76 KB |
Comments
What version are you using? For me, in 2.0.2, the last system begins with bar 75, and there is no shift.
It is very occasionally the case that the algorithms that govern how much music can fit on a system are just barely on the edge - like it calculates that 4.9999999 measures will fit, and depending on the phase of the moon, that might round up or it might not. This should happen less with 2.0.2 than with previous versions, as the font system has been replaced with one that is less system-dependent, but it can still happen occasionally. Perhaps that is what you are seeing.
Win 7 HP. MuseScore 2.02. official release.
Here is a screenshot of the end of the score immediately after opening the file:
Here is a screenshot after pressing Ctrl + A (or any other operation):
Another curious thing: If I save "score_after", then close and reopen the file, it reverts to "score_before."
In reply to Win 7 HP. MuseScore 2.02. by geetar
The calculation of whether a courtesy key signature is needed or not is precisely one of the cases where indeed it is most likely to be just barely on the edge of being able to fit or not. This was much improved for 2.0 over previous releases, but no doubt there could still be some corner cases remaining.
I can't reproduce on your score as is because for me, the last system starts with measure 75, not 76 as is shown on your screenshot. The previous system started with 72, not 71. No idea where the discrepancy first started.
However, I can reproduce the shift if I manually insert a line break after measure 71, to force the next system to start with 72. Somehow the code designed to reduce the likelihood of courtesy key signatures causing problems does not seem to be working here, not sure why.
It would be worth filing an issue on this. There may be two unrelated things going on here - one question is why despite the new font system are we seeing different initial layouts, and then there is the shift. Be sure to mention that it may be necessary to insert a line break to start a system with measure 72 to see the shift.
Meanwhile, the workaround is to lock your layout by inserting line breaks and then reducing stretch to ensure there are no roundoff issues - which is not a bad habit to get into generally, not just for this score, if you care about consistent layout.
Issue filed at https://musescore.org/en/node/70706.
When you say insert line breaks to lock the score, does that mean that every system should have a line break after it?
In reply to Issue filed at by geetar
That's a personal choice. Depends on whether you are attached to the specific layout you are looking at or whether you would prefer MuseScore remain free to shift things around as it seems fit. I often manage my line breaks for maximum readability, so in those cases, I prefer to add line breaks everywhere. Edit / Tools / Add/Remove Line Breaks has a command just for this purpose. In other cases, though, I am happy to let the layout "float" as necessary. it's really up to you.
In reply to Issue filed at by geetar
I can reproduce it with the same score on OS X, which means that this is issue #45221: Layout changes after action.
In reply to I can reproduce it with the by Isaac Weiss
Well, not necessarily. Same symptom, but not guarantee the cause is the same.