"Reduce stretch" has bad effect on other measures as soon as stretch factor reaches 0

• Mar 16, 2015 - 08:19
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
  1. take an existing score, with notes, line breaks, etc.
  2. Select a measure, preferably the 1st of a system, e.g.:
    1.png
  3. Right-lick-> measure properties
  4. set layout stretch to 0, the smallest possible value in that dialog, apply with 'OK', e.g:
    2.png
  5. now further decrease measure stretch by using the shortcut '{', here 4 times:
    3.png

expected result:
Either nothing happens, we're already at the lowest stretch value
or
That measure gets further condensed and the measure stretch goes negative

Actual result: the following measures get affected by the reduce stretch and even flows into the selected measure, see above

another problem, with image mode, saving in screenshot mode: the blue selection rectangle is not part of the saved image, only indication that we're in screenshot mode rather then pront mode is the coloring of the notes. Guess that should get reported separatly

Comments

• May 29, 2015 - 00:11

I'm getting the same bug in 2.0.1 (Windows 7). Looks like Layout > Decrease Stretch (or "{" shortcut) erroneously allows the stretch to go negative, reducing the measure's logical width below the minimum rendered width.

People reported this in 2009 (#3176: MuseScore weird behaviour on adding less stretch) and 2010 (#4926: Bars overlap when shrunk).

This interacts unintuitively with the displayed Layout Stretch value in Measure Properties, which is evidently enforced as nonnegative in that part of the UI. Negative stretch values, as above, display as 0.00; Cancel doesn't touch the underlying negative value, while Apply or OK set it to zero. (Should this be another bug report? It'll be "fixed" when Decrease Stretch is.)

Reply

• May 29, 2015 - 09:16
Title "Reduce stretch" has bad effect of other measures as soon as stretch factor reaches 0 ⇒ "Reduce stretch" has bad effect on other measures as soon as stretch factor reaches 0

So we should disallow stretch to become < 0.0? Is 0.0 itself OK? If non, what should be the smallest possible value?
Testing with disallowing values < 0 shows quite good results, i.e. fixed the problem mentioned here. But if you do this for all measure in a system, things go haywire. This is true before that change though, so might be a different issue...

Hmm, disallow values < 0.001 seems to work OK, and is still small enough for the dialog to show 0.00.

Reply

• May 29, 2015 - 09:22

I have some difficulty with this thread, or I misunderstood something. If I apply the value O in 'Measure Properties ", I get this in a measure of" My First Score".
valeur O.jpg
Under certain conditions of layout, this can lead to an overlap on the other measure.

But that is exactly the same behavior with the shortcut "}", right?
If press x times this shortcut for the same measure, I may get this.
shortcut.jpg
Is that a reason to disable the shortcut ?!! And so, in the same idea, is that a reason to disable the value O (I personally use and it is useful to me).

If there is overlap, using the inverse shortcut "{", or increase the value in "Measure Properties", right? Just a little common sense.

I agree that the only existing bug concerns the "Cancel" button that does not work in "Measure Properties".
But as already stated, you change the value, and that is all. Especially, the "Apply" button works, so, you can see on the screen at any time the result of your action. So, where is the problem (except therefore the behavior of the "Cancel" button)?

Reply

• May 30, 2015 - 03:09

Fragile indeed. I wouldn't depend on this! Instead, maybe think about adding measure on the next page and not printing that page, or something like that.

Reply

• May 30, 2015 - 14:31

My undestanding is that 0 is ok but not a <0 value. I think it should be solved in cmdDecreaseStretch and not when setting the value or reading value from score.

Reply

• May 31, 2015 - 07:25

I'd need to check again, but IIRC 0 was not ok, try it on all measures of a system (using system breaks). That was why I picked 0.001.

And indeed very bad thinks happen, try it yourself, I'm a hard time describing what I see here
in a score add some system breaks, so that you end up with one system spanning 3 measures
change stretch of all 3 measures to 0 and after the last change watch what happens.

Reply

• Jun 17, 2015 - 09:03
Status (old) fixed ⇒ active

Bad things are happening if the effective stretch (userStretch * layoutStretch) goes < 1.0. This is now fixed.
The userStretch for a measure has to be >= 0.0. A zero value produces a measure which is as tight as possible, independent of the available space in the system.

Reply