Stretch having miniscule affect on mmrests
Reported version
3.0
Priority
P0 - Critical
Type
Graphical (UI)
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
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?
Fix version
3.1.0
Comments
Here's the attachment I forgot. See https://musescore.org/en/node/281570 for the original report.
In reply to Here's the attachment I… by Marc Sabatella
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
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"
Exactly.
Whatever, now, the expected behaviour is the one of the 2.3.2 (and previous)
For example, first try, and I observe it worked in 2017 (october 17) with 6c735b8.
I take a look and check further (curiosity!) :)
So, I note the change on last April 13 (or end April 12)
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:
While with a version (december 2017 here) which worked, the minimum is largest with same conditions: treble clef template/2 systems.
"By design" ?
Once more in #283266: Strech in multimeasure very limited
Came up again in https://musescore.org/en/node/284727
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.
https://github.com/musescore/MuseScore/pull/4862
Also improves default width of mmrests, making them less "greedy" in taking up available space on a system, and also more consistent in size within a system (still proportional to duration, just less directly).
Sounds like this came up in https://musescore.org/en/node/287483 though I'm not positive.
Fixed in branch master, commit ade9f8ce28
fix #281651: stretch not having much affect on mmrests
Automatically closed -- issue fixed for 2 weeks with no activity.