System dividers

• Sep 9, 2013 - 05:19
Reported version
S5 - Suggestion

System dividers (also known as system separators) are thick diagonal lines that appear in large ensemble scores (usually orchestra, opera, etc.). See attached for a sample screenshot.

They are used for scores that alternate between pages with a single system per page (when the full orchestra is playing) to pages with multiple systems per page (because only a few instruments are playing and the rest of the instrument staves are hidden). This helps the conductor follow the score.

They are not typically used in small ensemble scores where the number of staves per page does not vary.

Attachment Size
Capture.PNG 657.6 KB


I should also mention that the system dividers may appear on the left side only or on both sides of the page (depending on style preference).

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.

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?

Actually system dividers are not normally used in chamber works, so the option about number of staves makes sense. (I assume they refer to the total number of staves in a piece and are not referring to the variation of staves you get on some systems if you hide empty staves)

System dividers are typical in larger orchestral works where some systems are hidden so you get a different number of staves per system. I know the implementation in Finale is frustrating because it has to be the last thing you do.

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.

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:


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.

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).

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

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

Attachment Size
systemdividers.mscx 14.6 KB
Status (old) fixed closed
Reported version 2.2 3.0

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

Status (old) closed active

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

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.

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.

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.