Event doesn't reach its logical recipient.

• Sep 6, 2021 - 07:04

We can stretch a measure with

     Shift-[
or
    Shift-]

... but we must have the measure itself fully selected to do so.

The stretch commands have no effect if a note (or other child object of the measure) is selected. UPDATE: Discussion below has revealed that Stretch commands work ONLY if the first note/chord of a measure is Range selected.

Since only one object can be "measure stetched" (the measure itself) I'd think it safe to pass the event until it reaches the measure. That would certainly streamline layout tasks for me, as it would allow me to stretch a measure while objects remain selected.

There are many such behaviors afoot. I'll add some more examples here as MuseScore reminds me.

scorster

Comments

• Sep 6, 2021 - 08:05

@scorster
Maybe you should be a bit cautious before you change any requirement to have a measure fully selected before the specified action takes effect.

For example: Tools > Voices > Exchange Voice 1-2 only has an effect when the measure is fully selected. Currently if you want to exchange voices for only the first two beats of the measure, you're out of luck. That is a situation where it might be useful in future to differentiate between a partially selected measure and a fully selected measure.

Reply

• Sep 6, 2021 - 21:55

DanielR wrote Maybe you should be a bit cautious before you change any requirement to have a measure fully selected before the specified action takes effect.

Not sure I follow Daniel. Are you asking if I want/recommend the requirement of a full measure selection to invoke Measure Stretch?

If so, actually I was suggesting the opposite, that a measure should not need to be fully selected for stretch to have effect. (And it turns out there's more to the selection story, as illuminated by Doug Kerr in this thread.)

scorster

Reply

• Sep 6, 2021 - 14:04

Are you talking about stretch applied (passed through) to a single measure?
Do you find yourself using
Shift-[
or
Shift-]
on a single measure most of the time, or on a range of measures?

Reply

• Sep 6, 2021 - 21:44

Jm6stringer wrote >> Are you talking about stretch applied (passed through) to a single measure?

Yes. A single note exists in a single measure, so I'm suggesting that the containing measure get the stretch event. Otherwise, to stretch the measure, we must first reselect in some "acceptable way."

Similar logic could be applied to a Range or List selection that spans across multiple measures. Is that what you were pondering?

Jm6stringer wrote >> Are you talking about stretch applied (passed through) to a single measure?

Do you find yourself [measure stretching] a single measure most of the time, or on a range of measures?

I'd say I mainly stretch single measures.

scorster

Reply

• Sep 6, 2021 - 16:16

Hi, scorster,

You say:

"... but we must have the measure itself fully selected to do so."

It is more complicated than that. What seems to be required is that a "selection frame" appears around one or more (contiguous) selected notes, one of which is the first note in the measure (but not necessarily embracing all notes in the measure).

But in any case, with respect to the stretch function, it would seem that, among other things, the "current measure" would be (as itself) susceptible to the stretch commands. In some notation programs, the definition of "current measure" includes the measure in which the insertion cursor resides. But in MuseScore, there is no "insertion cursor".

So perhaps, as you suggest, any measure in which one or more notes are selected, whether the nature and cause of that selection results in a "selection frame" appearing or not, should be susceptible to the tender mercies of the stretch commands.

As to the Tools > Voices > Exchange Voice 1-2 command, that is quite a different matter (as we are dealing with various contents of a measure, not the measure as an entity), and I make no suggestion that what I recommend above should apply there.

But, while I'm in that neighborhood, I agree that it would be desirable to be able to select one or more notes and, if we do Exchange Voice 1-2, any of the selected notes that currently are assigned voice 1 would be changed to voice 2 and vice-versa.

(Oddly, if one selects several notes in a measure in a way that results in there being a "selection frame" shown, and does Tools > Voices > Exchange Voice 1-2, that swap is made for all notes in the measure. It is not necessary that the entire measure be selected.)

Best regards,

Doug

Reply

• Sep 6, 2021 - 21:35

Doug Kerr wrote ... perhaps, as you suggest, any measure in which one or more notes are selected, whether the nature and cause of that selection results in a "selection frame" appearing or not, should be susceptible to the tender mercies of the stretch commands.

Hi Doug,

Thanks for your excellent summary! That's my point exactly.

Here are examples of Measure Stretch working with Range Selections:

• on Range Selecting a whole measure (by shift-clicking an area of the measure’s “white space”) we see a "selection frame" around the entire measure, and the measure is responsive to "stretch" commands

• on Range Selecting the first note or chord (by shift-clicking the note or a chord tone) a "selection frame" appears and the measure is responsive to "stretch" commands.

• on Range Selecting two or more contiguous notes in a measure, including the first note in the measure (using Click—Shift-click) a "selection frame" appears and the measure is responsive to "stretch" commands.

• If one or more contiguous notes in a measure, including the first note in the measure, are selected using Shift-drag (a "marquee/lasso selection") a "selection frame" appears, and the measure is responsive to "stretch" commands.

In contrast:

• As implied above, if a Range Selection does not contain the first note of the measure the measure does not respond to "stretch" commands.

• On selecting one or more contiguous notes in a measure, (via Click--Control/Command-Click,etc.), a List Selection occurs, thus no "selection frame" appears, and the measure is not responsive to "stretch" commands—even if the selection includes the first note in the measure.

• Same goes for discontiguous List Selections; the measure is not responsive to Measure Stretch.

There seem to be double standards here ... and List Selection is again a second class citizen.

scorster

Reply

• Sep 6, 2021 - 22:21

It seems to me that SHIFT+] or[ working when the first note of a measure is part of the selection range, is more of an anomaly than a feature.
If you select middle notes (especially dis contiguous notes), MuseScore has no idea what you want. Do you want space at the selected notes? There's a different command for that.
Isn't the command designed to stretch the measure, not part of it?

Reply

• Sep 7, 2021 - 00:05

I think the issue here is the the stretch/shrink command means, "Stretch/shrink this (these) measures(s).

So the question is, in what ways can we indicate what we mean by "this (these) measure(s)".

scorster suggests that work in this area would be expedited by having as many ways to "give a (single) measure the nod" as possible. Since by definition the command can only work on an entire measure (or several entire measures) there is no dilemma of, "If we tap a measure to be affected by stretch/shrink by selecting a note in the middle of the measure, how does MuseScore know what we want to do". If we hit Shift-], MuseScore would know that we want to stretch the measure within which that note falls.

Doug

Reply

• Sep 7, 2021 - 02:48

bobjp wrote>> ...the instructions on how to use stretch [say] to select a range of measures. Not parts of measures.

True. The Handbook expresses that Stretch commands works on a Range of measures, or the whole score, which is a Range of measures.

But surely sometimes the user might want to stretch a single measure. And this is indeed possibly but, as you point out, undocumented.

  • We can stretch a single measure only when the full measure is Range Selected—and alternately by making an intra measure Range selection that includes the measure's first note.

  • Interestingly when I Range select a full measure and the first note of the next measure (and any additional notes in the second measure) Stretch commands affect both measures.

UPDATE: Turns out the following comment is in error:

  • In constrast, if I select the last note of a measure and the select next full measure, Stretch command have no affect.

Reply

• Sep 7, 2021 - 04:27

You're right. Pffff. I used Control/Command by accident. Sorry for the errant report on that particular issue. I'll update the post if I can.

But again this is an undocumented feature. As you pointed out the Handbook starts the topic directing us to "select a range of measures" which implies or specifies whole measures.

There's more to this that meets the reading eye.

scorster

Reply

• Sep 7, 2021 - 05:07

Safe, sure, but then a user would reasonably expect that if they've only selected part of a measure and apply stretch that it would only apply to the part selected.
Note that you can relatively quickly select the measure of the current selected items by holding down CTRL+SHIFT then hitting left then right (I will say I think there's a case for a single command to do this!).
In fact, just CTRL+SHIFT+left is enough, because as you noted, it's sufficient for the first note/rest in the measure to be selected for the command to work (which does seem a bit odd).

Reply

• Sep 7, 2021 - 06:50

Dylan Nicholson1 wrote ... a user would reasonably expect that if they've only selected part of a measure and apply stretch that it would only apply to the part selected.

That expectation never crossed my mind. If it had, it would have been immediately erased after I first saw the behavior in action.

One way alleviate potential misunderstanding would be to change the function's name from Stretch to Measure Stretch, and that name would be more apt, because that's what it does. AFAIK this function cannot stretch parts of measures. If that function appears in future version of MuseScore it could have a distinctive name and shortcut.

Note that you can relatively quickly select the measure of the current selected items by holding down CTRL+SHIFT then hitting left then right (I will say I think there's a case for a single command to do this!).

Agreed. And I think you've stated on the forum that MuseScore's "white space" method selecting measures is problematic. I certainly find that to be true, so much so that I often have to zoom in on a busy measure to successfully shift-click to select it.

Maybe in another thread we can address the possibility of stretching parts of measures, but I'd rather not see that discussion develop here as it may subsume the thrust of this discussion.

Thanks for your input! Much appreciated.

scorster

Reply

• Sep 7, 2021 - 21:47

Some people have failed to see that I’m not trying to stretch the selection alone, nor modify the selection. In fact, I want to preserve the selection AND stretch the whole measure (which is Musescore's normal Stretch effect.)

Here’s the issue in a nutshell: With the first note of a meausre Range Selected the Stretch commands affect the parent measure, so why don't we get that behavior with any intra-measure note selection? Just seems logical. Likewise it would make sense for Stretch commands to affect all measures of any measure-spanning selection.

It just seems logical and convenient for Stretch commands to affect the obvious relevant “parent” measures: even when there is no “whole measure” selection, without the requirement that the first note in a measure must be Range selected, and without the need—as questionably stated in the Handbook—to apply Stretch only to a Range of measures.

To RECAP: I simply want Stretch commands functional with the current selection, whatever that happens to be:

• If the selection is within a single measure, Stretch commands affect that whole measure *

• If the selection spans multiple measures, Stretch commands affect those whole measures *

 * For better or worse, given MuseScore's implementation of Stretch, other measures on the same system also respond in kind. (As far as I know, we don't have the option of dragging a barline to stretch one measure while shrinking the adjacent one, and leaving all other measures on the system unaffected. Overture has this nice design pattern, almost. In an attempt to keep this topic on track I'll illustrate Overture's "stretch" GUI in another topic. )

scorster

Reply

• Sep 7, 2021 - 23:11

Dragging barlines to adjust measure stretch would definitely be a neat feature, I used to do that in Encore. But I'm not sure it's compatible with the way measure stretch is done in MuseScore - even though it's a property that technically only applies to an individual measure, as you note, it affects the width of all measures in the same system. So you'd need to calculate new stretch values for every measure in the same system to ensure just the barline you'd dragged tracks the mouse, but all the other barlines stay where they are - I suspect it might not even be possible in all cases.

Reply

• Sep 7, 2021 - 23:36

Dylan Nicholson1 wrote >> Dragging barlines to adjust measure stretch would definitely be a neat feature, I used to do that in Encore.

Hey, good to know that you have experience with Encore!

It's amazing how the "original" plucky little notation app got so many design patterns right. Other apps have had decades of opportunity to harvest aspects of Encore's UI and UX, but they've overlooked many jewels of simplicity. Of course, Don Williams took Encore's elegance much further in Overture, but back to topic, presently an Overture barline drag affects only (and ALL) the measures to the right of it; not ideal—but at least it does not affect any prior measures.

I hope someday a MuseScore task force that looks at Overture's interface. I'd gladly participate. Despite Overture's flaws (mostly stability, copy/paste issues and truly fouled up layout features) it indeed has lots of great designs. But like Encore's comatose stagnation over the last decade, Overture too seems frozen in amber as of this last year.

>> ...technically [when Stretch] applies to an individual measure ... it affects the width of all measures in the same system. So you'd need to calculate new stretch values for every measure in the same system to ensure just the barline you'd dragged tracks the mouse, but all the other barlines stay where they are - I suspect it might not even be possible in all cases.

I'm surprised to hear that. I agree it would be "neat" to see this feature in MuseScore—which overall is sooo lovely to use!

Hopefully someone will figure out how to implement a "barline-drag stretch" that only affects the measures sharing the barline.

scorster

Reply

• Sep 8, 2021 - 15:18

FWIW, I did a trial implementation of connecting stretch to horizontal drag of barline. It's trivial to do and kind of fun to play with. But, making it track in any predictable way is another matter. That is, dragging a barline to the right increases stretch, sure, but the measure may get wider faster or slow than I am dragging, depending on the layout, and as you say, it affects the rest of the system in ways that might not be expected.

What is really needed is support for a fixed width setting, so dragging the barline X units can simply set a fixed width of current width + X. I see there is work being done on an "equal width" option but that's not the same, even if it is sometimes referred to as fixed. Implementing a true fixed width setting would also be pretty trivial I think, we'd just have to decide how to expose that in the UI.

Reply

• Sep 8, 2021 - 20:07

Marc wrote I did a trial implementation of connecting stretch to horizontal drag of barline. It's trivial to do and kind of fun to play with. But, making it track in any predictable way is another matter.

Wow Marc. Thanks for looking into this!

I'd also like to see option for:

• fixed width measures
• measures within a system at "equal widths"

Great if one or both are part of the path to barline drag implementation.

Much appreciated!!

scorster

Reply

• Sep 9, 2021 - 17:47

Marc Wrote >> Wouldn't be even better to be able to stretch partial measures?

The option to apply Stretch to partial measures would be a wonderful addition to MuseScore! And indeed, while suggesting that this thread's discussion not drift in that direction, I gave a nod of appreciation toward that goal. I've started a Request post for further discussion partial measure Stretch.

You're asking if the addition of "partial measure" Stretch is better than resolving the Stretch issue where the command fails to reach it's logical recipient. That does seem more logical overall—if MuseScore is headed in that direction any time soon. But the "command fail" issue would still exist if the user has a single note or chord selected ... unless that note or chord is the first note/chord of the measure and is Range selected. (I.e. there'll never be a need or option to stretch a single note, so if any single note/chord is selected, why not target the command the measure itself, as MuseScore does when a measure's the first note is Range selected?)

Can you post a real-real-world and use case where selecting only a partial measure before applying stretch to the whole measure would be desirable?

Yes. Here's an example that bears merit in a world where Stretch only affects full measures: I have a partial measure selected. I decide I want to stretch the measure and then continue editing the selection. And I want to do so without needing to first select the measure (to stretch it) and, to get back to work, then reinstate the prior selection—as stated in the original post.

Reply

• Sep 10, 2021 - 18:50

Can you post a real-real-world and use case where selecting only a partial measure before applying stretch to the whole measure would be desirable?

I'm feeling a bit boxed in by the question's wording, which asks, "Why it would be desirable to make a partial measure selection prior to stretching a measure." It's not desirable. It just happens a lot—so I don't want to comment on or defend that.

But I'll answer the following question, which better illuminates the issue I've attempted to communicate:

Can you post a real-real-world use case where applying stretch to the whole measure would be desirable when only a partial measure is selected.

Yes. Here's another use case:

I want to increase a measure's width by invoking Stretch. But it's tight quarters (the very reason I want to Stretch the measure) and this often makes measure selection unmanageable unless I zoom in. Each time I click the "white space" MuseScore selects a neighboring child object of the measure. On my eighth attempt at measure selection—purely so I can stretch it—I very consciously wish the Stretch command would have effect even if the selection is any child object of non-measure spanning ilk.

Granted this scenario might lead one to conclude: "Well, the real fault is with full-measure selection." Indeed. Nevertheless, as a workaround—until we have "partial measure" Stretch that affects selected notes—I'd like to see Stretch commands affect measures even when invoked with just one or more child objects selected.

When/If MuseScore implements partial measure Stretch perhaps a new, separate command would make sense. Then one could stretch the selection OR the measure while the current selection remains intact.

scorster

Reply

• Sep 10, 2021 - 23:02

Dylan,

I believe that in the usage case posited by scorster the problem is not that (a) Ctrl-[ does not work to select the first note of the measure (and thus make the measure responsive to Layout Stretch) but rather that (b) having done that, the selection he had in place (and wants to keep in place for further work) is destroyed by that maneuver.

Doug

Reply

• Sep 11, 2021 - 00:02

Yes I did see his post mentioning that, I guess my question would by why would it make sense to adjust the measure stretch if you know you're going to do further modifications in the current measure? Measure stretch really makes the most sense when certain measures look too narrow or too wide for an already fully notated system (across all staves, I might add).

Reply

• Sep 11, 2021 - 00:16

Dylan,

I understand.

The other usage case scorster mentions is where congestion makes it difficult to select a measure in the usual way, and I think his point is that it would be handy if we could just select any handy thing and then invoke Layout Stretch.

Of course, we can always select any handy thing and then do Ctrl-Shift-Left.

Doug

Reply

• Sep 11, 2021 - 05:12

Hi Doug,

Thank you. The comments you made in your last two post perfectly reflect and summarize my points.

Doug Kerr wrote >> "[scorster's] point is that it would be handy if we could just select any handy thing [i.e. child object not shared with any other measure ] and then invoke Layout Stretch."

Totally nutshelled it Doug. (But then, I though I had too.)

Previously in this thread I was asked to provide use cases. So here's a third use case scenario:

There has been discussion of difficulties invoking full-measure selections a via white-space clicks. At 100% zoom I find full-measure selection problematic only about 10% of the time. However, when finishing a Part zoom out so I can readily see the overall density of measures, and from that perspective use Stretch to fashion an "even gray" finishing touch. When zoomed out today for that purpose, full measure selection was problematic about 80% of the time. The click inevitably selected some particular child object of the measure—and this is one of the main points here: If that object is not a range selected first note (or chord) the Stretch command proves ineffectual.

In contrast, when any note is selected I can easily add or remove a line break, why not also Stretch a measure?

As mentioned previously, one can simply cite the lack of a dedicated "command click" for full-measure selection. But I think it's deeper as we see this sort of UI stuff strewn about MuseScore. And while usually it's easy to remember and workaround odd UX quirks, other times its not.

scorster

Reply

• Sep 11, 2021 - 05:18

Dylan Nicholson1 wrote>> ...why would it make sense to adjust the measure stretch if you know you're going to do further modifications in the current measure?

Hi Dylan,

Thanks for your continuing interest on this topic.

Sometimes I invoke Stretch just to see if it automatically looks better for the measure, and the line as a whole. And sometimes the further modifications do not affect the distance between notes or the overall width of the measure.

And I answered your question more completely here

scorster

Reply

• Sep 8, 2021 - 21:00

I'm not sure I'd want dragging a barline to fix the width of the measures either side, if I add more material later on or extract parts etc. I would still expect the widths to be adjusted accordingly. But perhaps you could have a fixed "adjustment" factor that is added to the initially calculated width?
Also if you're referring to what I think you might be, the "equal width" mode is just a new view mode, not intended for print-out/export to PDF etc.

Reply

• Sep 9, 2021 - 15:33

FYI: only the selected measure is affecting affected by the stretch - you can verify this in measure properties. Only reason other measures then change width is because of the normal horizontal justification of systems - others you'd end up with a ragged right margin. But that's all internal to the layout algorithm. You can verify the actual "user stretch" of other measures is unaffected via Measure Properties. I can't really imagine that anyone would actually want this to be otherwise.

Reply

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