Handle measure with too many notes to fit on a single system

As far as I can tell, this is not specific to MusicXML; it's just a fact that if you have a measure with a lot of notes in it and have too large a staff size selected, it's not going to fit. It isn't clear what one should expect here, but I've decided to turn this into an open-ended feature request. I could imagine MuseScore detecting this situation and automatically reducing staff size or note size to force it to fit, or splitting the measure automatically so it continues across systems, etc. Meanwhile though, you can do any of these things manually.

I tried splitting a measure manually in a file from which the parts had been deleted and the program crashed. It continued to do so even after the file and program had both been closed and reopened.

Do you believe this is related to the current issue? Seems more likely to be separate. Please file a new issue with the score and steps to reproduce the crash.

I was looking for something else and tried it for fun. In measure 7, select the 5th 8th-note in the LH and follow instructions for splitting the measure and the program will crash, at least it did for me, if I attached the right file.

Issue filled (related to the attached file in the last comment #4): #75991: Split a measure in direct relation (time duration) with some tuplets owned to another staff causes crash

Came up again in #270774: Too many notes in measure to fit on page leads to layout problems and https://musescore.org/en/2.2#comment-826890

There has been some discussion at #305435: Automated system break for big measures, I'll try to sum it up.

There seems to be a general consensus in allowing some automation: when a measure alone is bigger than the page, the measure should be broken; using the existing groups in timesig properties, after the last group that fully fits. A warning should be displayed offering to change staff/page size instead.

In the case where the user wanted the break to be earlier, there are two suggested implementations for this customization: the first, to control this directly from time signature properties; the second, to control it using mid measure system breaks.
I'm a supporter of the second option, because it's more flexible and because it would allow to control measures with extra beats (those made too large for the page using the timewise/insert mode).
For this mid measure system breaks option to be possible, system breaks should be extended to allow to insert them in any place, not only in the end of measure. To not interrupt the workflow of some users and because this feature would be not very commonly used by the average user, pressing only enter would force the system break to be in the end of the measure, so a specific key combination should be pressed (suggested: shift + enter) to put the break somewhere mid measure.

The logic for breaks should be changed too. They should be stored in the rhythmic position of the element that is broken and moved to the next line, although they should be displayed and activated from the last element of the previous line. As @mike320 pointed out, this could, in turn, help fix a known bug.

Also, there is a workaround consisting in splitting the measure: split the measure, add the break, select the barline (if there's more than one instrument select similar elements in the same measure) and make it (/them) invisible, exclude the newly created measure from the measure count. Total eight to ten clicks (add 1 if selection after split command was enhanced).
The result of the workaround 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.

One point I'd like to make. I think never automating this is the best way to go since it's not a common traditional notation though it is more common in more recent music. This would mean a shortcut and a symbol in the Breaks and Spacers palette would be the best way to handle this. Most people, I think, would want a long measure to be moved to the next system as is the current case. There are also many options to fit the long measure on the previous system.

In my view, the only thing the time signature properties should be used for with this is to determine the beaming after the mid-measure break. Treat the new measures as though the break did not exist for beaming purposes. One final thing, I support the auto invisible end barline but do consider that some may want to keep it visible and permit this to be overridden.

I have seen scores with dotted bar lines at the split of long measures. I am ambivalent about automation. The situation of overflowing measures is rare and I suspect that to be useful there will be many option needed to meet individual users' needs. No/dotted/solid ending barline is just one example. I suspect most users would just make the odd break they need manually the way they like it rather than setting up the options so that an automated break would be "the way they like it". But who knows, there may be some users who would find it useful.

I think that some clever UX design could make these mid measure system breaks useful and flexible to appeal to the highest number of people that need them, instead of resorting to the clunky workaround.
I'm by all means not an expert, but it comes to my mind that after inserting a mid measure system break, the barline (no/dotted/solid) could be changed in the system breaks inspector.

FWIW, some other notation programs do offer both automatic and manual mid-measure system breaks:
* Automatic:
* Manual: https://www.rpmseattle.com/of_note/how-to-work-with-system-and-page-bre…

My idea for a better system would be a fourth type of line break, which splits the measure. For now, I have to use the workaround... (sigh)

If you really want to do this - as shown in the example at measure_won't_split.mscz - then one cheat way is as follows:

1 Show the score in Continuous view.
2. Make up a suitable time signature to contain a selection of the bar in question - say 8/16.
3. Select the long bar, then change its time signature - here from 4/4 to 8/16. That should create two bars.
4. Hide the new time signatures with the 'v' command.
5. Reset the time signature following the new bars (8/16 back to 4/4)
5. Hide any elements not needed - again with the 'v' command - perhaps removing the terminating lines at the end of relevant bars.

Eventually you should get something like this:

One snag is that this throws out the bar numbering - spot the numbers 7 and 8 in the example above - but if one is really keen, then that shouldn't be too much of a problem.

Do such very long bars occur often?

Another possible solution for some long - but not extremely long - bars is to make sure the output page is in landscape mode - though I'm not sure if MuseScore does that. Maybe it does?

Bar numbering can be worked around; see the last paragraph of this previous comment https://musescore.org/en/node/72041#comment-1046038. And, yes, the output page can be in landscape mode.

These long bars (almost) never occur in the common practice period of Western Classical Music (1600-1850), but there's a vast quantity of music that is better represented in paper without bars; or music with some or all bars too long to fit in a system.

I can understand that nobody is volunteering to do it and that the core team is too busy with more important features, but I don't understand the oposition to the idea of automatic splitting. I think it instantaneously enhances the output of music that would otherwise flow out of the page no manual intervention made. Of course, the option of doing hard manual mid-measure brakes would increase the flexibility of the feature.

Automatic system breaks can also be made more flexible with some parameters, as in this program:

I would say I'm not opposed to someone trying to implement some sort of AI algorithm to detect a good place to split a measure and then do it automatically. I would object to this being something forced on those of us who prefer to exercise our own control over where to do the split - implementing some sort of fancy AI algorithm shouldn't make people's jobs harder. And to me there are far more valuable things people who have that sort of expertise could be working on. But again, if it happens to rise to the top of someone's personal priority list and they want to have a crack at implementing an optional feature for this, I have no objection.