Layout jump triggered by instrument names on hidden staves
This bug and similar ones have been my biggest problem with MuseScore for a long time. I can't tell you when exactly it happens, but it seems to happen to one in three scores I make these days. It's not always about stretch, sometimes it's vertical offset for lyrics or accents. I do feel like it has something to do lyrics though (I work with choirs a lot).
1) Open "Happier.mscz" below
2) Select bars 1-4
3) Press { to decrease Layout Stretch (bar 4 is now in the first system)
4) Save
Upon saving, the layout stretch resets, or at least bar 4 moves back to the second system.
Luckily, when exporting to PDF you don't need to save beforehand ("Happier1.pdf" below is before saving, "Happier2.pdf" is after), so there is a workaround of sorts. But being punished for saving regularly is terrible.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.4.2.9788, revision: 148e43f
| Attachment | Size |
|---|---|
| Happier.mscz | 17.54 KB |
| Happier1.pdf | 43.34 KB |
| Happier2.pdf | 43.2 KB |
Comments
(you're all but one)
I can confirm it though, never happened to me so far?!? (and I'm using MuseScore for choirs notes too, almost exclusivley)
In reply to (you're all but one) by Jojo-Schmitz
Then I'll try to add more examples if I can find them, strange!
I can't reproduce using 3.5 alpha on Linux, but I suspect that not because of anything fixed since 3.4, probably because what's going on is system-dependent, might depend on specifics of font handling. I'm guessing that the last measure is just barely on the edge of fitting or not, and the calculations are coming out different (like there being 2.000 inches to spar on that system after four measure but the fifth measure either comes in at 1.999 or 2.000 depending on some accident of the hardware. There used to be bugs where this sort of thing happened often - and it wasn't just floating point round-off like this - but we've fixed all the ones reported and I haven't seen a report in well over a year that I can recall, so I am inclined to believe one isolated example would be just the floating point roundoff. In which case, just reduce stretch one more notch to be safe.
I still can reproduce in the Alpha and the latest development build as well as the Beta, on Windows
In reply to I can't reproduce using 3.5… by Marc Sabatella
Reducing stretch another notch does not solve the issue; no matter how many times I decrease it, saving will always put measure 4 back on system 2. Actually, if I decrease and save a few times, the stretch seems to hit a minimum and it won't move anymore at all. The very act of changing stretch will put measure 4 wherever it belongs, and saving will always put it on system 2. So:
1) Open "Happier.mscz"
2) Select measures 1-4
3) Decrease stretch a bunch of times to hit the minimum → measure 4 will be on system 1
4) Save → measure 4 is now on system 2
5) Decrease stretch → nothing happens
6) Increase stretch → measure 4 is now on system 1!
7) Save → measure 4 is now on system 2
So the workaround isn't that simple, sadly. Again, I'll post an update here if I ever find another similar case.
I am able to reproduce now using 3.5 beta. It seems the stretch is being set correctly - if I check Measure Properties before and after the stretch, and then again after the save, I see the values I expect. So the stretch works, it's just the measure can't decide if it fits or not.
Even without changing stretch, even without saving, I can reproduce a similar issue:
1) load the score
2) make just about any edit - even changing the title
Result: measure 4 jumps up to the first system
So even with the score as is, MuseScore is having a hard time deciding about that measure. In the [past we've seen issues like this occur when there were courtesy key signatures involved, also a few other special cases like that. The only thing that looks suspicious to me here is the use of hide empty staves and the staff names that appear on the second system. Simply deleting the visible staff names didn't fix the problem, but turn off hide empty staves and deleting all the staff names did.
So that's my guess right now: the problem has to do with the staff names on the hidden staves that are sometimes being included in the layout calculations, sometimes not. And I can work around the problem by deleting the "long instrument name" from each of those staves (they aren't shown anyhow, so no harm there).
The good news is, if I'm right about all this, it might an easier fix than some of the other similar "layout jump" issues we've seen. I'll look into it further.