"Stretch" renamed in 2.2

• Feb 20, 2018 - 21:01

In the current development versions of master and 2.2, there have been a few changes to the names of features in the UI. Some of these, like renaming "line break" to "system break," I don't feel strongly about, but one of them, I do: "stretch" has been changed to "measure width."

There are three menu commands affected by this change—Layout / Reset Stretch is now Layout / Reset Measure Width, and so on—and one label in Measure Properties.

I disagree with this change, because I believe it is misleading and confusing. Stretch is not the same thing as measure width, as can be very easily demonstrated in the default "Untitled" document (which has line breaks, or rather, system breaks) by selecting an entire system and increasing or decreasing stretch. "Measure width" is something that can always, or should be always, directly discernable on the score. Stretch is a property whose effects may or may not be visible. I think this change should be reverted, or at the very least postponed for further discussion until after 2.2.

Comments

• Feb 20, 2018 - 21:17

I share your reservations, but then, I would claim "stretch" isn't very accurate either. After all, if it is surprising that there might be times when increasing the "width" has no effect, it could be equally surprising that increasing or decreasing "stretch" does not, either. Worse, "stretch" is not even remotely intuitive, whereas at least "width" conveys something of the intended effect.

So I really don't have much opinion on the change - six of one, half a dozen of the other, but I'd rather have the full dozen (hmm, did I just invent that)? I guess I also have reservations about making gratuitous changes that can potentially confuse existing users or people referring to existing printed documentation (ahem).

But I know I would like us to consider a truly better way of dealing with this for 3.0. First, to consider whether a menu command is really even the best way to do this wat all. To change relative spacing of measures within a system, it probably would be more natural to allow dragging barlines. To force MuseScore to allow more measures on a system than it is otherwise, probably be more natural to just have a command to do this more directly. There may or may not end up still being a need for a command to increase or decrease the thing we now know as "stretch", but if there is, then I think it might make more sense to discuss the naming, in this new context.

Reply

• Feb 21, 2018 - 14:14

"stretch" has several problems that "width" has not, esp. if you think about translations:
a) is it noun or verb?
b) what is the opposite of "stretch"? (In German, for the verb: "dehnen" and "stauchen")
c) while "increase stretch" might work (rather than just "stretch"), "decrease stretch" IMHO does not (and no opposite exists?), "reduce stretch" might though, even if "decrease" is the opposite of "increase"

OTH I have to agree that a change seems needed, alone to avoid confusion about the similarity with "Minimum Measure Width" in the edit style dialog.

For the record: the changed happened in f8abc0bd (for master) and 296ecb2 (for 2.2)

OK, here we go: https://github.com/musescore/MuseScore/pull/3484
Opinions?

Reply

• Feb 21, 2018 - 16:43

I think it's good. Stretch is both a noun and a verb—"stretch" (the noun) refers to how much it can "stretch" (the verb). I'm not sure if it has an opposite, but reduce or decrease makes sense to me; as far as I know the two words have exactly the same meaning, so I'd stick with "decrease" to match "increase."

Reply

• Feb 21, 2018 - 18:10

I agree there it's a somewhat unnatural thing to say, but to me it is important to be clear of the relationship between decrease and increase. "Reduce stretch" is also unnatural. And neither is technically accurate. So I still say, "decrease" is the way to go for now.

So, we might as well talk about what actually is happening technically (at least for 2.x; master may be different but probably not fundamentally so). Maybe that will help people think about better ways of describing this in the future.

Each measure has a "nominal" width that is determined by its contents and your current settings for measure spacing and minimum note width. We figure out how many measures we can fit on a system given these nominal widths. But if we placed measures on the systems that way, the right margin would be ragged (it's like what unjustified text look like, as in what you see in this forum). So, we "stretch" each measure proportionally within the system so we have an even right margin.

That amount of "stretch" per measure happens totally regardless of your own stretch settings. You own stretch setting (the "user" stretch as it is called internally) is basically just multiplied by the measure spacing when calculating the nominal width. The internal stretching to right justify happens on top of that.

So there are really two different stretches here - the one you specify that is incorporated into the nominal width of the measure, and the one performed by MuseScore to right justify.

The MsueScore stretch is always a factor greater than (or equal to) 1 - that is, it always results in a measure being wider than (or equal to) its nominal width. There are no cases currently where MuseScore will elect to make a measure smaller than its nominal width. But the user stretch can go either way. Increase stretch means a measure's nominal width will be more than it otherwise would be, decrease stretch means a measure's nominal width will be less that it other would be.

So decreasing the user stretch will indeed generally make a measure less wide than it otherwise would be, but it might take quite a lot of decreasing user stretch before you actually end up completely eliminating the effect of MuseScore's own stretch. Meaning, even if you decrease stretch for a single measure by one or two notches, it is still being stretched wider than its nominal width would have been with no user stretch at all. You literally are decreasing the amount of stretch - it's still stretched, but not by as much.

However, there does come a point where you might decrease user stretch by more than MuseScore's own stretch was going to be. In these cases, you are are actually compressing the measure to be narrower than its nominal width would have been with no user stretch. And at that point, saying you are "decreasing stretch" is quite inaccurate - you are literally compressing the measure.

The thing is, there is no special point at which this happens - it might be two notches for one measure on one system, but four notches for another measure on another system. Worse, it might be two notches for a given measure on one system, but four that that same measure on another system, because the internal strwtch applied was greater on that system because it wasn't as full.

Add to this Isaac's original comment about measure width not being accurate either - decreasing user stretch for all measures on a system will have no apparent effect on the width of any measure - and we have a situation where there really is no obviously correct term to use here.

Maybe this means we need to think harder about terminology, maybe it means a different approach internally that is easier to describe makes sense, maybe it means something else.

Anyhow, mostly I just wanted to pad my word count stats :-)

Reply

• Feb 21, 2018 - 18:22

Would be great except as I said, there is no single obvious point at which it changes from decreasing stretch to actually compressing. For a measure on a relatively underfull system it might be five notches of decreasing stretch before it starts actually compressing the measure past its original nominal width. For a measure on a more full system, it might be just one notch of decreasing stretch before the measure actually is compressed compared to its nominal width. For another measure on an extremely full system there might not be any decreasing of stretch that happens - the very first notch of applying that command might be literally compressing.

Worse, even if we could make the distinction, its irrelevant in the real world because no one ever sees the original nominal width (well, in theory you might on an unfilled last system, although actually I think some amount of stretch is applied even here in an effort to try to make the results not be too far removed from how other systems look).

Reply

• Feb 21, 2018 - 18:24

I'm still working on my first Bible so I'll go ahead and pipe in with an opinion.

As long as stretch remains in the name in the English it will help to distinguish it from measure width in the styles menu as stated elsewhere in this thread. As far a "Reduce stretch" versus "Decrease stretch" both sound equally fine to me and there is no variation in the meanings of them. I'm glad Isaac noticed this, because it was inserted under the radar and would have no doubt caused some unneeded confusion after the release of 2.2 among the English speakers such as: "Where did the stretch go?" "Which measure width do we change?" "Why doesn't { and } change the measure width in the style settings?"

I'm a bit short of adding a Habakkuk, but that'll do for now. ;)

Reply

• Feb 21, 2018 - 19:02

OK so if "decrease" vs."reduce" doesn't make any difference in meaning, then indeed "decrease" wins.

Still, to me "stretch" goes only into one direction, towards bigger, while "compress" goes into the other direction, and this is my whole problem with "decrease stretch", nobody (?) would come to the idea to say "increase compression". And I'd most probably still translate it into German as "d e h n e n" and "stauchen" (just like it currently is), which is almost the same as "stretch" and "compress".

Reply

• Feb 21, 2018 - 19:14

I'm not sure if you read my entire description, but again, the problem is, "decrease stretch" really does not mean compression unless you go far enough. All measures normally get stretched, but ones with "decrease stretch" applied simply get stretched less than they would have otherwise. Only once you go "too far" is a measure actually compressed, and in any case, the distinction is irrelevant to a user because he doesn't know what the nominal width was in the first place. I just don't know a simple way to convey this in a menu item.

But FWIW, in English, "increase compression" makes perfect sense. And it's exactly what is really happening one you decrease stretch by so much that you have now made the measure smaller than its nominal width.

By way of analogy, imagine a rubber band representing a measure. It has a nominal length - it's length if you just lay it on the ground. Glue three of them together end to end and lay them across a piece of paper, and now you have an unstretched system. MuseScore always starts out by stretching those three rubber bands to fill the width of the paper. If you take one of those rubber bands and grab the two ends and move them closer together, it's still stretched at first - just not as much. So you have very literally decreased the stretch.

Eventually, as you keep moving them closer together, you reach the point where the rubber band is not stretched at all - it has reached its nominal length. Keep moving them closer together still and now the rubber band is being compressed. Keep moving them closer together still and you are increasing the compression.

So, when you first start moving the ends of the rubber band closer together, you are decreasing stretch. At some point it is not stretched at all, and now you are increasing compression. Saying you are decreasing stretch at that point is technically inaccurate, but saying you are increasing compression from the beginning is also inaccurate - there was no compression until you first decreased the stretch down to nothing.

if you can summarize that in a one-line menu item, I'm all ears. Right now, though, I'd rather avoid creating confusion among existing users by removing a familiar inaccuracy and replacing it with an unfamiliar one. So, "measure stretch" keeps the familiar, maybe helps newbies a little too, and doesn't otherwise make anything worse. It's good for now, I think.

Reply

• Feb 21, 2018 - 20:14

"Measure Stretch Factor" is indeed more accurate; good call! It does strike me as rather technical-sounding, though, and I'm not quite so sure it's actually more clear except to someone who already understands what is going on behind the scenes. But I'm probably too close to it to be objective. So I will defer to the consensus.

EDIT: some posts crossed I think, anyhow, given that the context is a bit different in Measure Properties versus in the Layout menu, I'd propose simply saying "Stretch Factor" in both locations. Unless people really feel it's important to use the word "Measure" within the Layout menu.

Reply

• Feb 27, 2018 - 16:02

My understanding is that "Layout" was added to clarify the use of the term in the Measure Properties dialog, then also changed in the menu for consistency. "Measure" wouldn't have been helpful in the dialog any more than "Layout" is in the menu.

And FWIW, I said I would defer to the consensus, and I continue to say that. But I wouldn't complain if the consensus were to go back to the current 2.1 wording :-)

Reply

Do you still have an unanswered question? Please log in first to post your question.