Automated system break for big measures

• May 14, 2020 - 14:30
Reported version
S5 - Suggestion

If a measure is bigger than the page, MuseScore doesn't break it to the next system; instead, it shows its contents off-page.
Nowadays, one has to split the measure in two, make the barline invisible, and exclude the second measure from the measure count. That automatic break would be a nice feature to have.


Frequency Few Once

This won't be possible without splitting the measure. And doing that automatically and on the fly is something that probably just won't ever happen

In reply to by Jojo-Schmitz

Regarding the frequency, @Xinas also asked for it.

I know it's oversimplifying it, but that's a thing word processors already do. If a word is too big for the line, it is moved to the next line (something MS already does with measures), and if a word is too big for the entire page, the word itself is split (the feature being asked for).

FWIW, the main complication in implementing this would be deciding where to break the measure. I could imagine preferred locations being marked in time signature properties similar to how it works for beaming. Or just using the existing groups and break after the last one that fully fits.

In reply to by Marc Sabatella

Maybe, by default, the break should occur after the last group that fully fits. For customization, the 'system break' element could be extended, to allow to insert it after any rhytmic position*.

An option to the system break could be added in the inspector as well, to decide if the break, when it's in a place which is not the end of a bar, should be done, even if there was enough space for the whole measure to fit in the page (by default yes?).

*to replicate the current way of entering conventional breaks by selecting a measure and pressing enter, when in range selection, the element should be inserted after the last rhytmic position selected.

I'm not exactly sure of what you just said but breaking a measure in the middle to accommodate a system break is not common in most music so it should not be too easy to make happen like selecting beat 2.5 of a 4 beat measure and pressing enter. This currently applies the system break to the measure. Allowing for a mid measure system break is an OK idea because I've wished I had it at times. The mid measure system break should be smart enough to know that the new system in my example starts on beat 2.5 and beam the measure on the new system appropriately.

What currently is possible is splitting a measure before a selected note from either the menu or using a user defined shortcut. In theory you should be able to use the plugin to split a measure and start a new system already (as long as you have assigned the split measure shortcut), but I don't think beaming will be proper in my example. You would need to Split the measure, left arrow to previous measure and press return.

In reply to by mike320

@mike320, what you say seems reasonable to me.
So what if the system worked the following way: if the user presses "enter", a system break is added at the end of the measure without considering the position on the measure of the (last) selected note. If the user presses a specific combination, (I'm thinking of shift+enter), the position of the (last) selected note is taken into account and the system break is added after it, mid measure.

I think that the internal logic for the break should be "before x rhythmic position". For example, in a 4/4 with four quarter notes, if I clicked on the third note and pressed shift+enter, the break should be displayed above the staff on the end of the third note but it should be "stored" at the start of the fourth note. This way, if I turned the third quarter note in two eighth notes, the break would continue being in the same rhythmic position (I hope this paragraph is understandable :/ )

In reply to by Asmatzaile

Implementing automation just seems a lot of effort for not much gain when the need to split a measure over more than one stave is a fairly rare occurrence and the current manual method works ok. But as you say, users can ignore the facility, and my guess is that they will ignore it or override it unless the "where to split" algorithm is clever enough to match users' ideas of where the split ought to occur. Indeed, in many cases is is better to move a long measure to the next system rather than split it, unless it alone is longer than the system.

In reply to by SteveBlower

Indeed, in many cases is is better to move a long measure to the next system rather than split it, unless it alone is longer than the system.

I completely agree with you with that; the default behaviour should be to move a measure that doesn't fit to the next system, as the program does now (although it'd be nice to have an optional setting which splitted measures not taking into account whether they are the first of the system).

It's those extra-long measures, which even alone don't fit in the page, the ones which I think should be automatically broken (a warning that this happened should be shown to users in case they prefered to reduce staff size or augment page size).

I think storing breaks at the start of a measure while displaying them in the previous measure would probably help fix a certain bug where you can't get rid of a pause on a system break if the measure ends with a repeat. That idea I think is good.

Shift enter currently adds a page breaks but the idea is fine. I was concerned that the current results were maintained if this feature were added and a shortcut assigned.

Ctrl+Enter is the supported shortcut for page break. Shift+Enter is actually available. But, I'm not enthusiastic about this at all. It's an extremely rare corner case that you'd ever need this,. and it's already possible in exactly two clicks: one to split the measure (I have this customized to Ctrl+Alt+S), a second to add the system break. At least in theory - the selection is lost on the split command. So certainly, enhancing the split command to make a reasonable selection afterwards would be nice. Really, it should keep the same note selected that you split on, but this is one note past where want to add the break. So if this were fixed to work as most people would expect anyhow, it would be three clicks: one to split, one to move the cursor back a note, one to add the line break.

Consider most people would do this at most a couple of times a year, a three-click sequence seems more than sufficient.

But, I'm not against some automation, splitting the measure if it won't fit. That's as far as it should go. We don't need to provide a ton of overrides over this, because there is already a way to do that, by splitting the measure. Customziation over where the split happens in time signature properties seems more than sufficient.

In reply to by Marc Sabatella

Actually, the process is longer, as one has to make the barline invisible (add a click, other two clicks for selecting similar elements if there are more instruments than one, and the pressing of the key V) and exclude the newly created measure from the measure count (I'm on mobile and don't remember how many clicks this is... like other four?).
The result obtained with those nine to eleven clicks is not ideal: first, now the number displayed on measure:beat:tick is wrong starting from the split; second, if the user decides to change the page or staff size later, she/he has to re-join, and possibly re-split the big staff.

I feel that mid measure system breaks are a better way than time signature properties of handling the cases when the user doesn't want only the part that doesn't fit to jump to the next system, because a) the user would be able to contemplate different possibilities until they decided where to put the break faster than by being blocked by a popup, b) custom mid measure breaks would allow a more flexible layout, c) big measures are often created by using the timewise/insert mode, and I don't think those extra beats are controlled by timesig properties.
Moreover, if in the process of making those mid measure breaks the logic for breaks was changed and the bug mike320 mentioned was fixed, wouldn't that be killing two birds with one stone?