Measure layout stretch command goes into nowhere!

• Sep 23, 2020 - 22:20
Reported version
3.5
Type
Ergonomical (UX)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
needs info
Regression
No
Workaround
No
Project

When using measure layout decrease command "{" after reaching the minimum layout stretch, it seems that repeating the command makes it into a "virtual" measure decrease. The measure doesn't get any smaller (obviously), since the minimum stretch is reached, however, when you attempt to increase the measure layout back again, it won't increase the measure stretch right away. The reason for that is that "invisible" decrease has to be first brought back to "real" minimum layout stretch.

Example:

  1. any note-filled measure - press "{" repeatedly until the minimum layout stretch is reached
  2. continue pressing "{" let's say 10 more times, (leaves the measure stretch visually intact.)
  3. try increasing the layout stretch using reverse "}" command repeatedly. This will result in the measure staying the same for another 10 times the "}" command is pressed.
  4. Only after 10 "virtual" increase "}" commands have been pressed, the measure stretch starts visually increasing again.

I don't see any reason how this could be practically useful. For user experience it feels like a bug , which conflicts with the basic WYSIWYG concept.

Has it been brought up before?


Comments

Status active needs info

I suspect you are confused about what is going on. The stretch command is applied until it reaches the minimum value of 0, then it does nothing. You could hit it 100 more times and nothing would happen, the value satys at 0. But then a single increase takes it up to 0.1. I suspect you simply aren't seeing a difference between 0 and 0.1 because of the specifics of your particular score - the content of the measures, the number of measures on the system, the minimum measure width set in Format / Style / Measure, etc. You can at any time right-click a measure and view Measure Properties to see the actual stretch value.

If you think you have a case where something is going on above and beyond this, please attach the score and tell us which specific measure is behaving anomalously.

In reply to by Marc Sabatella

You are right, I din't look precicely.
The changes between 0.0 and 0.8 are NOT visible in the score, not at all.

  • "But then a single increase takes it up to 0.1. I suspect you simply aren't seeing a difference between 0 and 0.1 because of the specifics of your particular score "
    So which settings does the score need to have, so that it doesn't happen?

The example I described was done using a default score template. Avery simple one staff score made using system dialog upon starting the program. So that looks like a default behavior. The content of the measure - four simple quarter notes in the first measure, nothing fancy. I don't think there is anything special about that score.
Basically if the layout stretch in the measure properties is set to 0.0, it will take exactly 8 "}" keystroke commands, before there will be any visual increase of the stretch.

Attachment Size
Layout stretch.mscz 6.66 KB

Right, in this particular example, the way the algorithm works, it doesn't happen to have effect beyond a certain point. It's really not about settings or defaults, it's about content. These measures are practically final width is based on the fact that they are "stretched" to a great extent to fill the page width, and that stretch effect drowns out pretty much any other adjustments. Results differ for different measures in scores, depending on the specifics, as I said. But the initial width of measures is controlled by Format / Style / Measure / Spacing, with the stretch factor applied to this, and a combination below 1.0 isn't likely to have effect because it's going to make the default width measure less than the minimum.

Anyhow, it's certainly possibly, maybe even likely, that the algorithms will be revisited for MuseScore 4

In reply to by Marc Sabatella

Well, That's not something you want to have for the GUI that is mostly WYSIWYG based. Doesn't feel nice and is pretty much a potential source of confusion, because in that scenario the most likely impression the user gets is that layout stretch "doesn't work" for some reason. I hope it will be revisited.