Make Toggle System Break shortcut available when note or measure selected

• Jul 15, 2017 - 00:45
Reported version
Graphical (UI)
S5 - Suggestion

This was first brought up in this thread:

Currently you must stop typing (or use accessibility options) and select a barline to enter a linebreak while enter a score. It would be more intuitive if pressing enter inserted a line break in the measure where the note is selected. Logically the input cursor would move to the first beat of the following measure. This would make entering a score more like a word processor when using the keyboard, or even other input methods that allow for keyboard input.

MuseScore currently acts mostly like a word processor for music. When the make number of notes that can be entered on a line is met, a "soft" return is entered and the current measure is moved to the following line (or page if necessary). One effect of allowing this would be, for example, if the measure consists of a 1/16th note on the first beat, the current measure is automatically filled with the appropriate rests. Pressing enter at this point, would of course leave those rests in that measure and the cursor would go to the next measure on the next line.

Allowing for a selected measure having the shortcut applied would make it work like the palette entry currently does.


Also as requested in that thread, it would be nice if the shortcut worked with a *measure* selected. So, with any single element selected, we should attempt to find the containing measure and then apply the break to that (*internally*, breaks are applied to measure and not barlines anyhow). Maybe also support list selections, and apply the same to all unique measures. With a range selected, we could either apply to the last measure within the selection or maybe even all measures within the selection (would be a quick way to get one measure per line, occasionally useful).

Very good idea about the group selection.

I'm not sure what makes more sense with the range selection. I've started typing a argument for it each way, but the other way just made too much sense also.

Well as I said it's a very easy change, and I've got it coded three different ways now :-). So here three possibilities for what happens with a multi-measure range selected:

1) add break to last measure only
2) add break to all measures in range
3) add break to last measure in range but also last measure *before* range

Hear me out on #3: this would allow you to select say four measures in the middle of a system, hit Enter, and have them appear as a system unto themselves, with a break before and after. It's actually akin to what we do when adding a clef, key, or time signature change with a multi-measure range selected.

What do you think?

BTW, the behavior with an element selected is maybe *too* powerful as I have it. You can actually hit Enter with just about *anything* selected and it will try to find a measure to add a break to. So, articulation, dynamics, etc. I could back things off and restrict it to barlines and notes/rests.

Once it gets merged I'll go ahead and try it to see how it works.

My main concern is your BTW. If pressing return gives the same results as pressing N with a slur selected, then this would be totally unacceptable. The cursor jumps to the beginning of the score. In that case, I would limit it to notes, rests, measures and barlines (to keep the current results).

As far as 1), 2) and 3) is concerned, you get one of the three results with various ranges selected.

If you select a range and
1) press a note key, the last note/rest selected will become that note.
2) use a shortcut or double click for an articulation, all notes will get one
3) double click a clef, the clef is applied only to the selected range.

That list is of course not exhaustive. My point being that any of the results would be consistent with other actions. I kind of like 3, because it will allow the user to pick his line and the appropriate system breaks will be applied.

I think #2 is most intuitive. It's also the way that double-clicking the palette icon currently behaves for breaks, not to mention spacers (in the same palette), not to mention almost everything else (with certain exceptions).

(Speaking of that "almost everything else," it really, really shouldn't behave that way for brackets and braces...)

I guess I'm less concerned with consistency for the sake of consistency, more concerned with what is most *useful*. I think there should be no question that the vast majority of cases will be of wanting to select a single measure and apply a single line break. The question to me is, what other legitimate use cases might come up where apply multiple breaks at once might make sense, and how can we best support those use cases?

For the case of breaks every X measures we already have a built-in tool for that, no need to worry about the shortcut.

For a case where you might want to apply breaks all at once to random discontiguous measures, you can't do that by selecting the measures individually since discontiguous range selections aren't supported. You can do it by selecting the barlines, though.

The two remaining cases I can think of are the ones that map to 2) and 3) on my list.

If you want a bunch of single measure lines, perhaps as a prelude to creating some sort of meterless score, or to create blank manuscript paper, 2) is going to be the way to go.

If you wish to identify a set of measures and say "these should be on a line by themselves", then 3) is the way to go.

To me, the last of these is is the only use case that is both common ancd supportable, which is why I lean towards 3).

Even when it comes to consistency, I would argue that line breaks are more like clef, key, and time signature changes than they are articulations, and thus I'd still say this points to 3).

I guess if there is some other legitimate and common use case for which 2) is actually preferable, that is the sort of argument that would be more likely to sway me.

I'm really not happy with this. The logic of making it behave like key and time signatures might be a valid possibility, but despite the argument, this doesn't even do anything like that. Now breaks applied by shortcut behave like key and time signatures when applied by palette double-click, while breaks applied by palette double-click don't. Meanwhile, everything else which can be applied both by shortcut and by palette double-click behaves the same either way, except now breaks don't. And to top it off, breaks applied by shortcut now don't even behave consistently with themselves—when one measure is selected, a break is added to it, but when multiple measures are selected, a break is also added to the measure before the beginning of the selection.

I think you're overthinking a case that will essentially never happen. The basic case that 99% of users will use 99% of the time is applying one break to one measure. Right now we don't support adding multiple breaks via shortcut *at all*, and probably very few people will ever have reason to care that this new functionality is offered. And for those few cases where someone *does* decide they want to add multiple break at once, I can't imagine they'll be particularly unhappy that it works in a nice logical way.

But in any case, sure, eventually we can alter the double click behavior to work this way as well. It just wasn't a high priority for me right now, and as I mentioned, it is very likely the double click code is going to be rewritten anyhow, so any work done to special case breaks will probably be wasted time.

If the case is so rare, then why is it necessary to introduce this feature/unexpected behavior for it?

Should a separate issue be filed reg. restoring and keeping consistency between application via palette double-click and via shortcut in all cases?

It's rare because the feature doesn't exist right now: there is no way to add multiple line breaks using a keyboard shortcut. So there have been in the entire hostiry of MsueScore until this point, exactly zero cases of this. That's rare. As for why introduce new features: because they can be useful. If we didn't introduce new features, we'd still be at Musecore 1.0. I'm afraid I don't understand why you seem so uncomfortable with this useful new feature.

But sure, any place there is inconsistency between shortcut and double click, it is worth considering an issue.

I can definitely see its usefulness, but there has to be a way to achieve it with behavior that is internally consistent ("this is what happens when you add line breaks," not "one of these three different things may happen depending on circumstances") and analogous to similar things in the UI. You originally suggested that this is analogous to how key and time signatures are applied, but it isn't. Nothing else in MuseScore behaves like this, and there's no way it won't confuse people. I wouldn't be happy if #211466: Dynamics added by double click are horizontally centred, ignoring the style had been proposed as a feature, either.

Making palette double-click use the same action would get it down to just two different behaviors, which is reasonable enough.

First, it won't confuse anyone because 99% of people will simply never known about or use use this nice new feature. It never worked to add line breaks this way before, so people aren't used to it and won't be surprised by this because they simply won't know about it. And if they read about it, they'll simply say, "hey, cool" - i don't see what's confusing about it. Have you tried it yet?

Second, I don't see how you can say it isn't like clefs key or time signatures. It's almost exactly the same. What do you think is different about it? In all cases, the applied element is added both before and after the selected passage so that the selected passage is a unit in itself. That's the whole point. I wouldn't have proposed this feature if I hadn't already implemented virtually the same behavior for clefs, key and time signatures, and saw an opportunity to make this work like those.

Third, again, sure, it would be nice if the double click function got this same enhancement. So file the feature request. But as I said, it might not be dealt with right away, because any code written to implement that feature would probably end up being thrown away later if the code gets merged.

Breaks now do this when the shortcut is pressed, but don't do this when double-clicked from the palette. Key and time signatures only do this when double-clicked from the palette. That's now the same.

Obviously. It sounded like you were saying the feature itself is not similar at all, and that was what made no sense. Yes, once again, it is true that it would be nice to some day implement this feature for double click as well. We are in 100% agreement on this. So, like I said, feel free to file a feature request to implement this for double click as well.

I haven't forgotten about this, just been sidetracked with lots else.

A sort of related thought that could apply soon to master: we're hopefully about to have the ability to add any palette element by user-definable keyboard shortcut (see But this means adding a break via palette shortcut would potentially work differently from adding it via the command shortcut. Same for clefs, keys, etc. We could poitentially special case here, but note to self - if/when the palette shortcut code is merged, we might consider removing some of the special commands we have now and just assigning those shortcuts to the palette directly.

Also, another sort of related thought: what if you could apply start/end repeats to a region by selecting it and hitting the shortcut? Another case that is kind of similar to clefs, key and time sigs, and (now) breaks - we'd apply one thing before the selected passage another after. We also do this for the loop markers, although that's handled totally differently. I wonder if there i anything else that makes sense to special case for range selection in a similar way?

Bumping this to gauge whether it is still worth pursuing for 2.2. I kind of would like to, but maybe people can play with this on master and see how they like the behavior?

Since there still seems to be concern about the actual behavior in the case where multiple measures are selected, let me summarize the situation:

Currently in 2.1, pressing Enter does nothing with a range selected - it only works work a barline selected. Doesn't even work with multiple barlines list-selected via Ctrl+click - has to be a single barline only. The behavior is to toggle, so a break is added if no break is present, but deleted if one is present. If a page break is present when you hit Enter, the line break is added to the measure, so you end up with both a line break and a page break.

Currently in 2.1, double-click on the palette does not work on a barline - it only works on range selections. The break is applied to each measure within the selection (even partial measures). But it doesn't toggle - it simply sets the break for the measure. That means also it removes the existing page break.

So as you can see, already quite inconsistent. And I recall having received exactly zero complaints about this in all the years it has been this way :-) So let's be perfectly clear: my change does not create any new inconsistencies. It actually closes the gap, by making the most common use case - a single measure selected - work the same for both keyboard and palette. Probably no one has ever even thought of trying to double-click the palette icon with anything but a single measure selected (or barline, which doesn't work).

That said, while the inconsistency doesn't bother me a bit, I would like to see the double-click behavior improved as well. So I am now thinking I might as well go ahead and implement cmdToggleLayoutBreak for 2.2 - basically borrowing the implementation from master. No reason this shouldn't work.

Hopefully this satisfies everyone. The only question is what the expected / most desirable (not necessarily the same thing!) behavior if a range comprising multiple measures is selected. My vote is the clef/keysig/timesig - like behavior I implemented for master - break inserted before and after the selection, so that's what I'm doing for now.

PR updated to bring 2.2 and master in line, also to enhance the implementation further so that palette double-click on list selection also goes through the same code.

So, for the sake of completeness, here is the new behavior:

  • palette double-click and Enter should now be completely the same with respect to layout breaks
  • with single or list selection, breaks are toggled on each selected element's measure
  • for range selection of single measure, break is toggled in that measure
  • for range selection of multiple measures, breaks are toggled before and after selection (similar to behavior for clefs/keysigs/timsigs)
  • you can apply break during note entry, just hit enter or double-click palette icon at any time while entering notes