Wrong width of last system once fill threshold exceeded
Ubuntu 14.04, GIT commit: 85b0ef0
1) new score, 4 measures
2) style / general / page
3) set last system fill threshold to 70%
4) add / frames / append horizontal frame
5) double click frame, stretch to right
Result: once edge of frame reaches margin, it jumps back to the left, and everything shrinks. Continuing to extended to the right and it jumps again once the threshold is reached.
See https://musescore.org/en/node/65126 for original report.
Possibly related to my changes for #24100: Horizontal frame at end of system followed by staff names
Vague description, I know, but hopefully I'll have it fixed before anyone has a chance to complain about the wording :-)
Comments
This is much deeper than I thought. The problem is not specific to frames. There seems to be a pretty basic flaw in the last system fill code. Here are other steps to reproduce similar behavior using just ordinary (empty) measures:
1) new score, 1 measure
2) set last system fill threshold to 70%
3) start appending measures with Ctrl+B one by one
Result: as you add measures, the system grows longer. You expect it to fill once you reach 70%, but it really never does. As soon as the system reaches the right margin, however, adding another measure actually makes the system grow *shorter*. Subsequent measures then gradually get longer until you reach the margin again.
If you set 50% for the threshold, it is clear this the thrshold is not being honored as expect. Following the same steps as above - adding measures one at a time - the system does not fill at 50%; more like about 80%. From looking at the code, I see that the calculation of whether to fill or not happens before stretch is applied. So I guess the "minWidth" of the system has hit 50%. But the actual width of the system is much greater because stretch is being applied.
It isn't really clear why stretch is applied. I've been considering this a good thing, as ragged last systems look way better by default than they did in 1.3 - not nearly so crowded. I had been assuming some fixed amount of stretch was being added. But no, I think whatever is adding the stretch here is doing so in a way that is causing the bug where the system length jumps in an apparently unpredictable way. That is going on basically here:
https://github.com/musescore/MuseScore/blob/de3a7c2608498358f4abcbb001d…
I'm unassigning myself because I think someone else should probably take a look at this. I have no idea what the right answer is here. I would hate the lose the nicer looking ragged systems, but the algorithm for stretching the last system seems to be pretty clearly off, and I can't say why without understanding more about what was *supposed* to be happening.
1) After seeing, I can say that there is two aspects for the initial message.
First, from 2014, May 19, until 2015, March 9, the behaviour is this: same jump back to the left, but by continuing to extend, the frame remains in the first system whatever happens, and the first measures overlap:
![may 19.jpg]( "may 19.jpg")
![march 10.jpg]( "march 10.jpg")
Then, I observe a change from March 10, and indeed, this fix of this issue might be involved: #24100: Horizontal frame at end of system followed by staff names
I notice the same jump back to left, but at a certain point of extension, the frame goes to the "second system."
2) For the scenario of the comment #1 (test only with "set last system fill threshold to 70%"), I note exactly the same result since more a year, on this Nightly: 56177c3, as described : "as you add measures, the system grows longer. You expect it to fill once you reach 70%, but it really never does. As soon as the system reaches the right margin, however, adding another measure actually makes the system grow *shorter*"
Yes, thank you. I believe the change on March 10 was good - the frame is supposed to jump to the next system, because it has become too large to fit. That is exactly the bug that was fixed - frames not being considered in the line length calculations.