Stretch having miniscule affect on mmrests

• Jan 11, 2019 - 23:46
Reported version
P0 - Critical
Graphical (UI)
S3 - Major

1) open attached score
2) select the mmrest
3) press "}", multiple times

Result: barely anything happens. Yet in other situations it works as expected. Somehow the way we calculate the sizes is not working well here, not sure why. Maybe it has to do with the fact the other measures are already so dense?


In reply to by Marc Sabatella

The most likely a side effect of this commit (November 20) :
To fix: #277821: Multimeasure rests extend when editing an element later in the score
- This nightly shows the described issue : ff8d766
- And with this one, after the fix, increase or decrease stretch for MM rests becomes ineffective (almost ineffective and / or with other unexpected results): 487dd5f

See with other test files:
mm rest TEST.mscz
other TF.mscz

The problem is that before that fix multi-measure rests just always increased in length, regardless of whether you increase measure stretch, decrease it or just do something other in the same system. So it is not clear whether measure stretching had any effect on MM rest before that patch.

"The problem is that before that fix multi-measure rests just always increased in length, regardless of whether you increase measure stretch"
Whatever, now, the expected behaviour is the one of the 2.3.2 (and previous)

So, I note the change on last April 13 (or end April 12)

  • With this nightly, the behaviour is as expected (decrease or increase stretch for mm rests works): a747b2b
  • Then it's broken , ie the previous behaviour (decrease or increase leads to always increase stretch - fixed now) appears with this nigthly: 82699c7
    If at first glance, nothing obvious, but something related to this last mentioned nightly/commit? Otherwise, there is four commits between the two mentioned nigthlies. Please check.

EDIT: and for the record, with the 2.3.2, the minimum length you can obtain is:
résult 203.jpg
While with a version (december 2017 here) which worked, the minimum is largest with same conditions: treble clef template/2 systems.
"By design" ?
résultat décembre 2017.jpg

I have figured out the reason for this. Dmitri's change was good, I think, but there were then other areas of code that need to be updated to compensate. For regular (non-mmrest) measures, we apply the user stretch during computeMinWidth() - specifically, we call setStretchedWidth(). But that function doesn't apply stretch for mmrests. Doing so fixes the basic issue here, but it also has an effect on the default width of measures that may or may not be good. I need to do a bit more investigation on the default widths of mmrests in different versions of MsueScore, check against Gould, published scores, etc.

Fix version