System dividers

Marked #37561: Mark between systems as a duplicate too

Citing a recent post of Marc Sabatella :
The symbol is present in the Symbols palette for current 2.0 builds, way down towards the bottom.
...
But you do still have to place it manually.

I suspect automation would be pretty easy to add, maybe for 2.1. A couple of style options, one to control whether it displays, one to control its position, then the thing would be generated automatically in layoutSystemRow() or thereabouts.

Oh that would be so GREAT ;)

The system divider can be found in the symbols. View > Master palette > Symbols towards the end.

Terrific.

is it automatic or do we have to insert it where we want ?
Edit : I just read Marc's post..... so w estill have to insert it manually

So, I'm looking at this now. It appears in Finale, you need to add these via a plugin, and presumably if the layout changes, you probably need to run the plugin again, maybe even delete the old ones manually? I was hoping to do better than that.

Sibelius displays them automatically using the equivalent of style options, which makes more sense to me. But I don't really understand the logic of the Sibelius options. The first one is "Appear when ___ staves of more", but to me, that seems backwards. In a score for, say, 12 instruments, I probably *wouldn't* want them to display on most systems; only the systems that (because of "Hide empty staves") have say only 6 or fewer staves. I guess the idea is you don;'t want them *at all* in a score for only a couple of instruments. I was thinking, though, that you might want control over which systems get the dividers and which don't. Which actually makes me think maybe something a bit more explicit a la Finale *might* make sense.

How do people who have used this feature in Finale or Sibelius feel about how it is implemented? Any suggestions?

Rignt, but even in larger works, I would think you nroamlly don't want system dividers *always* - just on systems that have fewer than the default number of staves. Eg, a piece with four voice staves and piano accompaniment, you might use hide empty staves to reduce the staff count from 6 to 2 on the systems that are piano only, and those might be the only systems where you would want the dividers. It looks like neither Sibelius nor Finale allow for that sort of thing. I'd like to, if possible.

I'm considering one style option to enable / disable the divders, but another to specify the maximum number of staves. So in my example above, you'd enable the option but set the max to 2. I am also considering making the dividers individually selectable so you can still move them or hide them individually.

I've got the basic code working quite well, just need to decide on how the options will look.

I'm currently thinking of having a checkbox to enable, a place to select the glyph to use, and horizontal/vertical offsets (from a default position which is centered below the respective barlines). There would be one set of these controls for the left side, one for the right. Logical place for them seems to be Style / General / System. Since you will be able to hide these individually, I am not going to worry for now about an extra option to specify a maximum number of staves, but it shouldn't be hard to tweak this once in place.

Initial implementation available for testing:

https://github.com/musescore/MuseScore/pull/2135

I expect to probably update this to add a new element type rather than piggy-backing on the existing Symbol. There are other refinements that could eventually be made as well, of course.

Fixed in branch master, commit 7ac83bf5fe

fix #22626: automatic system dividers

Fixed in branch master, commit 039188062d

Merge pull request #2135 from MarcSabatella/22626-system-dividers

fix #22626: automatic system dividers

Thanks Marc for the implementation! The feature will be in nightlies soon. Feedback welcome!

Scores saved with nightlies CANT BE OPENED with MuseScore 2.0.2 so be careful when you use a nightly.

Thanks for the merge!

To enable the divders, go to Style / General / System. You'll see independent controls for left and right dividers. Once enabled, they should automatically appear & disappear as needed. By default, they will center horizontally under the barlines, vertically between systems. The style dialog allows you to specify horizontal and vertical offsets that are applied to all dividers. You can also move or hide them individually.

BTW, by "appear and disappear" as needed, I just mean, they will appear between each pair of systmes, on the left and/or right side depending on which options you selected in the style dialog, and this is automatically updated as the score layout changes. There is no special heuristic for determing which systems should get the dividers - they will appear below each system except the last of each page.

Here's the relevant part of the dialog:

And how it looks when you select the left divider as I have done above:

Automatically closed -- issue fixed for 2 weeks with no activity.

I wonder whether this could be merged for 2.0.3 as well? It's a very nice, tangible feature, commonly seen in sheet music (likely to quickly become a popular choice if/when released).

It doesn't cause any compatibility issues that I can see (other than the obvious fact that they won't copy over to previous 2.0.x, but it doesn't seem to cause any bad things to happen in either direction—in other words, it's significantly more harmless than the cresc./dim. dashed lines which were judged fine for 2.0.3 anyway ).

Or are there underlying reasons why the code just wouldn't work?

Good question. I guess I originally assumed the new tags would cause problems for older versions. You are saying they don't - files with the system divider tags still load into 2.0.3? If so, then maybe this could have gone in, but at this point it's probably too late.

It warns "This file was saved with a newer version of MuseScore," naturally, but it certainly loads in 2.0.3, and more to the point 2.0.2, only sans system dividers. Try it yourself: My_First_Score.mscz (You may want to first open in a 2.1 nightly to verify that system dividers are present, then try 2.0.2.)

If it's too late, then oh well. But several significant changes have been made within the past twenty-four hours, so I hope it's a possibility.

(Accidental duplicate comment)

Right, 2.0.2 is what I meant. But, what about 2.0.1 or 2.0? I kind of thought maybe the new tags I added caused problems for some some 2.0-based release, and only later did we make MuseScore more forgiving of tags it doesn't understand.

As for being too late, I defer to lasconic and Thomas in that, but my thinking was, this adds new dialog box items that need translating and documenting, and we've passed the deadline for that.

Ah, yes—five days past the translation deadline. My bad, I should have thought of that. Thanks for straightening me out (and for adding this in the first place).

For 2.0.4?

Could someone with 2.0.1 or 2.0 test to see if it can handle a score with the system dividers turn on? Create a simple test score in master, turn on system dividers (but no other new features!), save as MSCX, then manually edit the version to "2.06" so there is a fighting chance of it working.

if the score loads into 2.0.1 and 2.0 with no ill effects other than the system dividers not being present, I'm fine with this being merged for a potential 2.0.4.

Should be easy to test with the portable apps

Edit:
Actually it turns out to be more difficult than anticipated: System dividers don't work properly in current master!
System dividers right showh up left. and changing their style doesn't take effect without switching them off and on again.

I tried anyway, 2.0.3 and 2.0.2 can read it without a problem (and without the dividers, of course), 2.0.1. and 2.0.0 can not read it, it reports 'invalid file format".

Seems that kills this featiure for 2.0

Implemented in master since quite a while

Impossible to backport to 2.0.4 without breaking compatibility with 2.0.1 or 2.0.0

Actually active, as the don't work properly in master, may need a new issue opened?

Good idea - new issue, with sample score steps to reproduce, etc

Let's keep this one open until a new issue has been submitted, as a reminder. I won't get round this before next Tuesday

See #111576: moving system dividers causes crash when using page settings dialog

For the longest time, the idea was to introduce the system dividers in 2.1, and indeed https://github.com/musescore/MuseScore/pull/2135 was merged into the then-2.1 branch. Is that still a possibility?

If we do this, we also need a fix for #111576: moving system dividers causes crash when using page settings dialog, I guess, for 3.0 and 2.1.

It would, however, still break compatibility with 2.0 and 2.0.1, which would crash on or refuse to load score containing these dividers rather than just ignoring them (like 2.0.2 and later would do)

Was that from a flaw in the original code? If it was a regression caused by the 3.0 layout changes, it wouldn't necessarily affect 2.1.

Donno, but certainly needs checking

It could be worthwhile to make a list of features for consideration, divided into categories:

1) things we can add with no compatibility issues whatsoever
2) things that don't prevent new scores from opening in older version but might layout differently enough to be a possible concern
3) things that don't prevent new scores from opening in older versions but will be more significantly different (eg, missing information)
4) things that prevent new scores from opening in 2.0 or 2.0.1, although they otherwise open in 2.0.2 and 2.0.3

I guess we should also consider implications for documentation. Some things that aren't inherently incompatible may nonetheless have documentation if it is something that we can't just mark "new for 2.1" but that actually changes how something worked previously (eg, moving some settings from dialog boxes to the Inspector).

My gut sense is for 2.1, we should definitely be considering anything in categories 1 and 2, probably 3 as well, but should be a bit more wary if they also hit category 4 (a given feature might have elements of multiple categories). But if we do decide to allow category 4 features, then that opens the door to *all* such features, including ones we maybe never considered before, which is why it could be worth going through and making a list to see what that buys/costs us.

System dividers are definitely category 4 because of the new tag - scores containing them simply won't open in 2.0 or 2.0.1 as far as I know. But also, the dividers will be missing in 2.0.2 and 2.0.3. One could consider this a minor layout issue (category 2) or a more significant bit of missing information (category 3).

Regardless of what we currently think about what we want for 2.1, it seems it would be good to have a handle on this every time we add a new feature that could possibly be considered for a 2.x release, as who knows if we will need to revisit this.

Sounds like a plan. And I can think of no one better to oversee it than the man who created the 2.0 Issue Hit List. ;-)

It's not possible to add new styles in 2.X without breaking compatibility. Versions <=2.0.2 had a bug and they crash on unknown style tag.

>=2.0.1. And they don't crash, but 'just' refuse to open the file. See https://musescore.org/en/node/22626#comment-485311