What's the best choice of implementing the control of whether or not to show single-stave brackets when empty staves are hidden?

• Feb 26, 2020 - 03:57

The current behaviour of MuseScore is not showing brackets which only span to a single stave if the user checks "Hide empty staves within systems". This behaviour can be wrong in many cases, such as orchestral notation, which normally has single-stave brackets.

The issue was raised in #296075: Allow user to choose whether or not hide brackets which span to a single staff when empty staves are hidden and has so far gained many replies. The simplest realization is to provide a checkbox controlling whether or not to show single-stave brackets. The downside of this design is that you have to toggle this checkbox for every score you want to change.

In one of the replies, Marc Sabatella offered a suggestion of implementation, which can provide the right result in most cases by specifying the transition point (default to 2 total instruments/staves (we'll have to choose one of them for specific implementation, but that's not the main point) in score) of the different behaviours: if a score has one or two instruments/staves, don't show single-stave brackets; if it has more than two instruments/staves, show single-stave brackets.

This indeed generates the right result in most cases, but also manifests a few problems:

  • The explanatory text for this option can be confusing. The shortest term that I can think of is "Show single-stave brackets if the total amount of instruments/staves exceeds: spin box". Besides being still very long, the main problem is that the relation between brackets and total amount of instruments/staves isn't easy to quickly understand. Anyone who's reading this post right now can understand, but what about unexperienced users? One thing is single-stave brackets, another thing is the total amount of instruments/staves;

  • The nature of this setting is ambiguous. This sounds more like a preference setting rather than a score style setting: in this score, there're only two instruments/staves, so don't show single-stave brackets; but in that score, there're more instruments/staves, so show single-stave brackets. It isn't intuitive to treat this kind of settings as a styling property for a single score;

  • This may not be something users would look for/notice. We, as humans, have more or less the tendency of skipping things that seem unrelated at first glimpse. If we want to find a control widget related to the visibility of single-stave brackets, it is beyond our intuition to look for a quantified setting instead of a simple checkbox.

I started (more precisely, continued) this discussion on the forum on Mr. Sabatella's recommendation. You're welcome to share your own opinion.


Some important context here:

1) In orchestral scores, it is indeed common to show brackets even in sections of only a single staff, and Gould specifically recommends it (p. 516). This is apparently subjective, and it seems apparent there needs to be a way to control behavior.

2) For choral scores, the situation is different, here the more usual convention seems to be to not show the brackets.

3) In orchestral parts, brackets definitely should not appear on single staves systems, even if there are sections where the part temporarily splits into two brackets staves for a divisi or solo passage. This probably also applies to piano parts from ensemble scores that switch between single and double staves (common in jazz) although here probably the user should have control because some no doubt will want the braces.

4) Lead sheets are like orchestral parts in this respect - even if the lead sheet temporarily splits into two or more staves (to show a bass line, for example), we don't want the bracket on the single staff systems.

So the challenge here is to come up with a scheme where the defaults are correct in as many cases as possible, while also providing a clear way to override the default where needed, and hopefully not creating compatibility issues along the way. My previous proposal got the defaults right in cases 1, 3, and 4 but required an override for case 2), and based on the way this result was achieved, there is probably no way to word the option in a way that is going to be immediately obvious. We could try wordsmithing it further, but I'm also interested in any completely different proposals for how to best handle this.

To me, it does somewhat obvious to try adding a property on the brackets themselves. The trick is figuring out how to get reasonable defaults in as many of these cases as possible.

Do you still have an unanswered question? Please log in first to post your question.