Some edits do not update systems (stretch, paste)

• Apr 2, 2019 - 20:16
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

This is an issue both in 3.0.5 and in master, although the specifics differ. Here's an example:

1) new score, treble clef template
2) fill bars with quarter notes until you reach the second system
3) select bar 1
4) press "}" until the measure expands enough to force the last bar on the system down to the next (for me with Letter as page size, it's ten times)
5) press "{", multiple times as desired

Result: the bar that moved to the next system never comes back up. It should after just one press of "{" but never does, no matter how much you decrease stretch in that first measure. Even other edits to that measure won't trigger a change. However, an edit to the bar that moved does cause it to move back up, as does a full relayout.

One clue as to what could be happening: if I keep pressing "{" to reduce stretch more and more on the first measure at step 5, it never appears to reduce past its initial width. So I think that although the measure does visibly get narrower as we reduce stretch, somehow this isn't fully taken into account as we layout the system. If I use the Debug menu to disable horizontal stretch entirely, the measure does continue to narrow, but the measure that moved down never comes back up.

Comments

• Apr 2, 2019 - 21:28
Title Decrease stretch does not update systems completely ⇒ Some edits do not update systems (stretch, paste)

It's not just stretch, actually. I can get a similar effect with pretty much any edit that pushes a measure to the next system, then either literally undoing that operation or just doing the opposite action. For instance, paste a long series of notes over a shorter one. If this pushes a measure (or multiple measures!) to the next system, then undoing the paste does not restore things the way they were.

This issue may turn out then turn out to be the same as #286028: Undoing system breaks doesn't always restore measure spacing to default. and/or #282503: Spurious line break after removal of line break on previous system

FWIW, I can fix all the symptoms I am observing by simply removing the following lines:

https://github.com/musescore/MuseScore/blob/master/libmscore/layout.cpp…

but I have no idea how safe this is, because I have no idea what these lines do. So far, though, no ill effects. If this was just some sort of optimization to avoid re-checking a measure we previously determined would not fit, then maybe we are better off without it.

Reply

• Apr 3, 2019 - 00:15

It's not really good to do this, since that is where we were setting rangeDone and thus knowing we can stop actively laying things out. Removing this code means we go back to laying out the rest of the score on every edit - clearly, not an option. We do still need to keep checking for more measures to fit on this system, although technically we may not need to keep calling computeMinWidth(). And we have to remember that the act of adding more measures to this system probably influenced the next system. We can't stop until we reach a system with no changes.

I'm kind of surprised it's been this long before we've had occasion to deal with this. It's really practically any operation that can cause this. Here's one obvious example: take an empty score, fill the first measure with 16thnotes, thus pushing a bunch of measures to the next system. Now select that first measure and press Delete. Again, the pushed measures don't return.

Reply

Fix version
3.1.0