Stretch having miniscule affect on mmrests

• Jan 11, 2019 - 23:46
Reported version
3.0
Priority
P0 - Critical
Type
Graphical (UI)
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

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?

Comments

• Jan 12, 2019 - 06:58

The most likely a side effect of this commit (November 20) : https://github.com/musescore/MuseScore/pull/4178/files
To fix: #277821: Multimeasure rests extend when editing an element later in the score
Indeed:
- 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

Reply

• Jan 12, 2019 - 08:16

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.

Reply

• Jan 12, 2019 - 08:54

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

Reply

• Jan 12, 2019 - 12:30

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

Reply

• Apr 2, 2019 - 03:58

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.

Reply

Fix version
3.1.0