Allow user to choose whether or not hide brackets which span to a single staff when empty staves are hidden

I don't see this violating the principle of orchestral music notation, as it is IMHO very uncommon to use 'hide empty staves' in such scores.
And I'd actually want that behaviour, like in SATB scores and a solo section

This is a very common issue in orchestral scores.

Problems arise in situations where you have the square brackets around each section, like the brass: Trumpet, Trombone and tuba (for simplicity's sake). You have hide when empty selected and only the trombone and tuba play, there will be no square bracket around the Trombone and Tuba as expected.

How common is it to use 'hide empty staves' in orchestral conductor's scores?

Unfortunately, there are situations where you want it (like a section in an orchestra score that temporarily reduces to one instrument because the others are not playing) and situations you don't (like in a violin part or a lead sheet that is mostly one staff but expands to two for some passages). So probably there should be a staff property to control this. Really, should probably be a bracket property, but that's probably harder to implement / expose.

Hide empty staves is indeed common in orchestral scores, more in smaller (book size) "study" scores than full size performance scores, but still.

Indeed, both ways are needed, furthe up I mentioned the SATB with a solo example

You may want both types in the same score though, so a bracket style setting won't help. So it got to be either a staff propertiy or a bracket property.

IMHO, this needs to be put near the top of the list for 4.0 and done right. The current method of bracketing instruments doesn't allow the flexibility that would make this user friendly. #279870: Proposed Bracket Functionality is one proposal, but it's not the one I'm looking for.

Score setup needs to permit the very common "strings" or more commonly "Archi" to identify the strings section, the allow nested inside to have each of the 5 strings. Under this we need the option of having multiple staves for each of the instruments. An example of where this would be useful can be seen in https://musescore.com/user/6105546/scores/5055217 starting on page 17. I believe the PDF is too large to attach so you can download it yourself from IMSLP.org if you wan to see it.

This would also allow for the existence of variable number of staves for other instruments as well.

Default would rather depend on what the behavoir was before maybe, to not render existing scored differently all of a sudden? Unless that was a downright bug (like the bold glissando text the other day), of course.
Not checked, buit how did MuseScore 2 handle this? If the same as MuseScore 3 currently, I'd rather keep that default.

An added bracket may result in a measure being pushed out to the next system, potentially screwing up the entire score layout, out of the blue after a minor or even patch update, we should avoid that.

The question of which is more "common" is entirely dependent on context. If you only look at scores and never look at parts (as one might if one is a conductor or a composition student as opposed to a performer or music librarian), you might find one usage more common, but then those who look at parts for a living will have the opposite experience. So I agree, default should be to not change current behavior for existing scores. That's not necessarily to say it can't be different for new scores, though.

I think all that I wrote is related to this discussion. I'm suggesting that we scrap the current bracket system rather than trying to piece together little changes here and there that each requires a special case. I don't see how to do this and keep 3.x compatibility but I've been wrong before.

I get where you are coming from, but am a bit less pessimistic. I would like to see a new design - how it would look to a user - starting from a clean slate. But then I would also like to think through how it could be mapped to the existing implementation - how it would actually be coded - with the least amount of disruption. It's possible we could end up with a scheme that works quite differently from the user perspective but requires only incremental file format changes.

I will take a step back. We can improve the current display of brackets by making it smarter. If there's a bracket around a staff, show it no matter if the bracket's top or bottom staff is visible. This won't break backwards compatibility.

In the next version, there needs to be a nested bracket system created that will allow the user to have one label for all of their violins I or french horns and only show the staves and part names associated with them rather than the current results. Example: create a Classical orchestra score and put notes only in the second horn and select hide empty staves. The result is a second horn staff with no label. With my nested label idea, you can put a curly bracket around both staves with the label of "Horns" and then put a label on the top staff that says "1" and the bottom staff that says "2." In my example, the horn 2 staff would then be labelled "Horns 2" when it is the only one visible. When both are visible, "Horns" would be in its current location and there would be a 1 before the first staff and 2 before the second staff. Ideally, this would be able to be applied to a grand staff or multiple instruments.

Perhaps I should start a forum discussion and see where it goes on the subject of Brackets and then write a suggestion for version 4.

This will break compatibilty as it canges the current default (of not showing a bracket if all but one of its staves are hidden)

I guess I didn't realize the brackets only disappeared when only one staff is visible. It's probably because I normally use only 2 staves at most for instruments. Never mind, I think the current function is probably the best we can do at the moment except showing the instrument name if only the bottom staff of a grand staff is visible.

What I am saying is that it is possible we might be able to change the default for new scores without affecting older ones. Certainly that's easy if there is a file format version change (which would generally mean, something we could only do for a MuseScore 4). But it's also conceivable we could make this happen without a file format version change. Consider, if it gets implemented as a property on the bracket itself, we could have it default to the current behavior but set up the palettes so the property is set manually, so adding a bracket to a score gives it the new behavior. There may be other options too.

As for parts, it is relevant exactly as I already a said: a violin part that temporarily splits into two staves for a divisi passage. You'll want a bracket (possibly) for the places where it is split, but you won't for the places where it is not.

In fact, this leads to another possibility: what if the behavior simply depends on the number of instruments? Show the bracket by default if there is more than one instrument, don't show if there is only one? This would, I think, get the majority of cases right with no need for additional options at all (not that we couldn't add one). Except I don't really understand the choral case.

My post crossed with the last few, I had forgotten to hit send, ignore any part that isn't relevant any more :-)

We could, against what we commonly do, write that property in any case, i.e. even if it is the (new) default, but read a missing property as "no", the old default.

Score vs. parts isn't the right distinction, because it misses the lead sheet case, which is a score but should normally still not show the bracket for the systems with only one staff showing.

Actually, with lead sheets, we have two cases to worry about. Some lead sheets might be a single instrument with two staves, others might be two instruments of a single staff. And neither user wants brackets on the systems of only a single staff.

So, I'll amend my suggestion. Instead of saying, we display brackets on single staves in scores of more than one instrument (and don't show them otherwise), we could say, display brackets on single staves in scores of more than "N" instruments, where "N" is an option you can set but it defaults to 2. So leads sheets are covered, string quartets are covered (I assume you still want to show the bracket on a string quartet even on systems showing just one instrument).

The advantage of the numeric setting is that you would not need to change it normally, it does the right thing in most (?) cases with N=2. Kind of like how we have "last system fill threshold" rather than a checkbox.

Well, I can't say I've thought this through, we're still in the brainstorming phase here. But I envisioned the option I referred to being a score style setting that most people would never need to change. The cases where you would is if you had a score for more than two instruments but don't want brackets on single staves (in which case you raise the threshold) or a score for 1 or 2 instruments where you do want it (in which case you lower the threshold). Maybe there is a way to emulate all of that and still get backwards compatibility that with just a single checkbox, but right now I'm not seeing it.

In any case, the only reason we'd ever need to add a staff property for this is if you ever needed both behaviors in a single score - like, the bracket displaying on the brass section even when down to one staff, but not for the percussion section. I would want to see some real-world examples of this from established publishers before I'd consider that worthwhile, but as long as it's done in a way that doesn't change anything about existing scores, I wouldn't stand in anyone's way who want to implement such an option. But, I'd also agree with @mike320, at this point I think it better to take a step back and really look at the big picture regarding brackets. What we don't want is to gradually introduce more and more "bandaid" options that then become that much more painful (in terms of breaking compatibility) to rip off if/when we do redesign all this. In other words, don't introduce options we likely won't want to support in a redesigned bracket system.

Right, so again, would you not agree my suggestion completely solves your problem, without negatively impacting existing scores that rely on the current behavior for parts or for lead sheets, and without the need for most users to ever change the default settings? If so, I would be toally in favor of seeing it implemented for 3.3.x

BTW, your picture is not of a full score but rather a consensed one. A full one would not hide the other brass instruments when they are not playing. As far as I know most publishers would be dealing in full, not condensed scores, so I wouldn't be quite as concerned as you are about a score not being accepted. But still, I agree it's worth addressing sooner rather than later, which is why I proposed something that I believe solves the problem without negatively impacting anyone who rely on the current behavior in the cases where it is the expected behavior (parts and lead sheets, for example), while providing a single simple override.

Makes sense to me. If eventually we add more bracket options there could be a new Brackets page, but it's not worth creating for just this one option.

Disclaimer - I haven't really thought through all possible outcomes, could easily be I'm missing something that would cause this to not really work. If you're considering implementing it, I'd suggest getting the logic going first and testing it, maybe making a "work in progress" PR for others to test - before worrying about the UI. I've been known to "steal" other settings to use in my testing, like before I go to the trouble of defining and hooking up a new control in the style dialog and the setting to go with it, just temporarily make my code use some other setting that isn't normally relevant, like, say, the minimum number of measures for an mmrest, or the measure number interval (both are ints, conveniently). That way if it turns out to be a dead end you haven't wasted as much effort.

So it is a score property, not a staff- or bracket property, right?

Came up again in https://musescore.org/de/node/298554

@Howard, want to make sure I'm not misunderstanding you here. Are you saying that in an orchestral score, if there was a section with 1 woodwind and 1 brass part visible on the score, you'd still want to see square brackets (used for delineating sections) applied to them?

Today, that's not the most common convention in orchestral scores, so def agree it should not be the default.

However, since you often see it in older scores (and I'm sure some like to see scores that way today) we should provide a way of doing it that is easy to manipulate.

I'm going to see if I can come up with a way of incorporating this into my 'Instruments' design.

Gould specifically states the bracket should be maintained even for single-staff sections. Behind Bars, p. 516: "An instrumental section of only one stave takes a square bracket". It didn't take me long to find examples of this in published scores, either (eg, Rite of Spring, Boosey & Hawkes, 1967 edition). So no doubt it is a thing.

Unfortunately, it's not what is generally wanted in choral scores, nor is it wanted in parts (eg, places where a part splits from a single staff to two for a divisi section), nor is it wanted in lead sheets. So that's the problem here: coming up with a scheme that produces reasonable defaults in all of these cases., and what our fallback is if we can't actually accomplish this.

Yeah, I read that line this morning and I was confused by it, since none of the examples she gives show this. I'm also wondering if Flute 1+2 on one stave would be considered by her to be a 'section' or not. Dorico (who cite Gould as their inspiration) certainly don't do it by default. It certainly is a thing though, no argument there.

On p. 533 she specifically mentions special cases for percussion. The examples I've found that don't include the brackets are pretty much all for percussion. I'm not actually seeing any other examples of either approach in Gould, unless you mean those on p. 515, which are about something else entirely - those are chamber ensembles in which there literally is only one woodwind, or only one string, etc. The case we are talking about here are larger ensembles where there is a whole section so the bracket appears on the section on pages where all instruments are playing, and the question is about what happens when hide empty staves is used to the section temporarily reduces to one staff. Is there a non-percussion (and non-vocal) example of that in Gould? Certainly possible, but I'm not seeing one that would provide evidence either way.

It's an important point - and seeing how Dorico handles it is also relevant - because if we can satisfy ourselves that it's OK to not show the brackets by default in these cases, this whole problem becomes much, much simpler. All we need is to add a property on the bracket, or staff, or score, or wherever, that defaults exactly as it does now but you can flip it manually. We could even arguably set up one or more of the orchestral template to enable that by default if we thought it made sense.

In my original question to Howard, I was asking about the case for momentarily having an individual part (a flute by itself for example). Orchestral scores do commonly have individual instruments that aren't part of a section too (piano, harp or single timp for example)

So we definitely are talking about that, not just sections - like a string section. In the case of having an individual part, like a trumpet that suddenly finds itself playing alone with no other brass on the score, I've seen scores give that player a bracket (these scores generally predate notation software by quite a bit). In more modern scores, I'm used to seeing these isolated instruments being displayed non-bracketed until one or more members of the group reappear.

The examples for different ensembles that Gould talks about are relevant to this. It's the same general principle with a few variations for different sizes and arrangements.

For instruments that aren't part of a section at all, you have full control over whether a bracket is added or not. So it really is only about sections that go back and forth between flutes appearing and being brackets with other being woodwinds for some systems, but being the only woodwin for other systems. This is the case I'd love to see a reason to believe Gould shows examples where the bracket is eliminated in those case, but as I said, I'm not seeing any examples one way or the other - just pictures of smaller ensembles in which the question of sections doesn't come up at all. If there really is an example where she shows flutes being bracket with other woodwinds on one system but appearing by itself with no bracket on another, I really would like to see it, as I would love the solution to be as simple as adding a bracket/staff/style property and keeping the defaults as they are.

To be clear, here are the specific standard conventions. In both these cases, the non-bracketed instruments are appearing in a score where there are lots of other woodwind and brass. Dorico follows this rule (example 1 & 2). Sibelius doesn't (as seen in example 3)

Obvious conclusion from this conversation is that we should provide options to allow both. Absolutely.

I didn't cite Gould. You did. I said I was confused about that particular line, because it's a little ambiguous. For example 'Flute 1 + 2' on one stave could be considered a section.

OK, I was confused by your statement "since none of the examples she gives show this (they generally show the opposite)".

Good to see Dorico defaulting the same way we do. Even if we don't see any similar examples in Gould, I'm personally inclined to call that good enough to support the idea of making a simple option the user needs to explicitly enable if you want a different result.

Maybe I’m confused, but I thought you have been arguing the default should change, so that orchestra scores would work the way you want without the need for setting an option.

If you’ve actually been OK all along with leaving the defaults the way they are, then we never needed my earlier suggestion. The whole point of that was to make MuseScore do what you wanted by default in these cases instead of what it currently does.

To be 100% clear: I am suggesting that the current defaults are fine as is. Those people who wish to see brackets on single-staff sections will have tonsettle for explicitly setting an option to get that result, even though that happens to be the result Gould says she prefers, and even though my read of the literature suggests it’s the more common arrangement. I’m not crazy about this because I do feel the default should be different, but if you are withdrawing your objection to the current default, I’m not going to argue.

I personally have not, and as I said, I remain a bit skeptical, because you and Gould had me pretty convinced earlier. But if Dorico does not show the bracket by default either - which seems to be the case according to the evidence posted by @Tantacrul - then that would constitute a possible counter-argument that I'm at this point willing to buy into if you are.

It does speak to the question of what the user might reasonably expect to have happen by default, based on what the actual modern standards are in practice. I remain unconvinced but open-minded. But all else equal, if it's a choice between behaving like Dorico )a program born just a few years ago, with complete attention to these sorts of detail) versus behaving like Sibelius (a progream born decades ago and with tons of legacy scores to support and perhaps get in the way them from doing the right thing by default even if they wanted to), I'll pick Dorico every time. but all else is not equal, there is still Gould to consider, and the fact that she sides with Sibelius is no small matter.

Clearly, for parts, lead sheets, thousands of people do rely on this, and they have every right to since these standards are virtually universal. Its only orchestral scores where there is a question, and frankly to me it’s not really settled, which is why I’d rather see more forum discussion.

Right nw I’m leaning that way, but it’s still not clear to me if it’s best done at the bracket, staff, or score level. Probably bracket?

"I don't see why the behaviour of another notation programme can prevail over everything we've been talking about here. Especially when you cannot provide any objective evidence at all."

Guys, can we chill out a little here? :)

So the first answer is obviously that there is no definitive and agreed upon version. If you look at any Tchaivovsky, Shostakovich or Mahler, you're going to see the convention for bracketing single instruments within a section. However, if you look at modern scores, you'll often see the non-bracketed convention instead. This means that stuff you get on IMSLP are generally going to use the older convention because they are older scores. Scores that are still in copyrighted can't be found there.

I spent some time looking through quite a few modern scores created by professional publishing houses (Birtwhistle, Georg Frederic Haas, Wolfgang Rihm, etc.) and found a lot of examples of the alternative, non-bracketed convention instead.

However - now that I've really spent some time digging - I've found more variation than I expected. For example, Faber use the bracketing system (which explains Gould's position - since she worked there), although it's not quite the same as what Howard was suggesting. For example, they would bracket a solo violin with the rest of the strings (and I'm not just talking about a momentary .div solo here) - although that's a minor detail in this wider discussion. Baerenreiter also use the bracketing system - although I've not looked through enough of their catalog to be certain. However, with publishing houses, if you see it once, you're likely to see it consistently.

I'm planning on going to a few libraries here in London (British Library & Royal College of Music) to look through some more scores by the more established publishing houses over the next few days and I'll get back to you with some more examples. Pity the Boosey & Hawkes online score view is down at the moment. It would be great to read through that in more detail.

Regarding Dorico, it is always worth paying attention to what they do when it comes to engraving rules - and less so Sibelius. Let's remember that they were the old Sibelius team and when they started Dorico circa 2012, they decided to alter a lot of things for a reason and they've paid great attention to engraving rules specifically. We'd be wise to always look at their implementation above the others when it comes to score presentation.

That said, it's by no means bug free and it could be an oversight too :)

I wonder - do either Dorico or Sibelius make a distinction between behavior in score versus parts versus lead sheets? Like I wonder, if you try creating a lead sheet in Sibelius that contains two bracketed instruments - not just one instrument with two staves - do it also retain the bracket when hiding empty staves? It could well be they face the same conundrum we do - how to make the defaults correct for scores as well as parts & lead sheets. They may well be choosing to mke one correct and have the other be wrong, just as is the case for us. But if Sibelius is somehow getting it right for lead sheets and parts (eg, a violin part that actually includes two instrument, one for the section, one for a soloist, with empty staves hidden), I wonder what they are using to make the distinction.

Anyhow, as I see it:

1) even though Gould explicitly says to keep the bracket for instrument scores, it's clear there is also precendent for not doing so, so I'm on the fence about what I'd rather the default be in an ideal world. When in doubt I lean toward Gould, but...
2) clearly, the default is already correct for parts, for lead sheets, and for choral scores, so even if we change the default for orchestral scores, somehow we'd want to not mess things up for the rest of the cases
3) while my earlier proposal did somehow almost achieve this (changing the default for orchestral scores while not messing up parts or lead sheets; only choral scores were adversely affected), it required use an almost-impossible-to-document option

So bottom line for me right now - unless something changes, which I remain open to - is we keep all defaults as they are and simply provide a way to override it.

As for the question of why not make it simply be a score property, two possible reasons come to mind:

1) What about scores that combine voices and instruments? Conceivably some will want to show the brackets on the instrumental staves but not the vocal staves.
2) Not a big deal, but when generating the parts, we'd need to explicitly force the option to not show the brackets, just as we explicitly turn on mmrests and turn off concert pitch. That's doable, but does give pause.

FYI - I attached an image of one thing that Dorico does, which is to default to an 'orchestral' option for bracketing, which you can change.

Regarding MuseScore, another thing I noticed is one (of many) potential short term fixes: brackets shouldn't appear for the Timpani in an orchestral part (this is quite common. Gould/Faber do this for example). However, even this tweak might cause loads of problems for the reasons you pointed out, Marc. And, although this convention is a lot more common, it's not universal.

Leaving aside the question of the most appropriate default for a moment, I do think there needs to be a lot of functional changes for how brackets work and I think they should be packaged into a comprehensive proposal.

One thing that particularly bugs me is that if I choose an orchestral setup by adding the instruments myself (I wanted a Rhapsody in Blue setup, which includes a bunch of sax players and a piano) no bracketing was applied at all, which is pretty frustrating. Even when I create an orchestral score and add sax instruments to it, MuseScore doesn't know what to do with them.

It will take time to create a proposal for how to solve this. I'll see if I can incorporate it into my current work and send it around for feedback. I guess it should include a bunch of proposed defaults to be discussed too.

The timpani case doesn’t need special handling - just don’t add a bracket, since you presumably won’t want one anywhere for that staff. It’s only the sections that vary between multiple staves and a single staff - and this sometimes want a bracket and sometimes don’t - where this is an issue.

Solving the broader issues would be good indeed, but if there is a short term fix for the issue at hand that doesn’t get in the way of further improvement, I’d support it.

Ah, to be clear, I'm talking about the bracketing for the timpani you see when you select 'classic orchestra' or 'symphony orchestra' as a default in the 'New Score Wizard'.

Oh, right - if we decide we want to, we can simply remove the timpani bracket from the template, no other design/code changes required.

"Automatically applying brackets can be even more frustrating for users"

Applying them automatically is a no-brainer and has to be done eventually. Anyone who is frustrated by bracketing that aligns with common convention is in a tiny minority. Not doing it automatically will result in beginner's scores looking wrong and will baffle new users in general, who'll have to spend time figuring out where we keep brackets and how they work (which isn't obvious).

With creation app design, the metric shouldn't be 'could this conceivably annoy someone', it should be 'what benefits the majority of people'.

And regarding things like the timpani being bracketed or non-bracketed, when searching for a default, we should be looking at what the big publishing houses are doing, what is recommended by Gould and what is implemented in apps, like Dorico. Sometimes these things go against our personal preferences. I for one, think we should pick a publishing house, look through all their conventions and then use them as our model. That way, we have a rule book and don't need to keep bickering.

Lastly, we also need to make these things easy to change and customise. If we do that, then the defaults won't be so draconian.

By the way, can you send me a copy of an orchestral score that puts all its instruments in one bracket? I'd be curious to see that.

Thanks! That's really unusual. I also notice they prefer the braces to combine violin 1 & 2! Really odd. I'm used to seeing that for splitting one section into two parts. I actually have my own pocket score for a Frank Martin piece. I'm going to dig that out.

I see this in a number few older editions I have too.

FWIW, I'm ambivalent about having brackets added automatically, to me adding them myself isn't really so onerous. I don't see how finding brackets on a palette is harder to discover than adding dynamics or fermatas o double bars or anything else. But, since brackets do relate to adding isntruments, it would be nice to be able to do this directly while adding instruments. If I were to try to design something for how I'd like, I could imagine the instrument adding interface could have an "add section" command that allowed me to choose the bracket, then add instruments to the section. And ideally, kept the notion of the "section" as a first-class object in the score, making it easy to, for example, grab the whole woodwind section and move it below the voices or whatever.

I recognize that's pretty off-topic, but it came up, so...

@Mark
"I don't see how finding brackets on a palette is harder to discover than adding dynamics or fermatas"

The question isn't how hard they are to find, it's that many users - especially people studying music in high school - will likely not even know that they have to be added. I didn't really know the rules for bracketing when I started studying composition and was certainly guilty of relying on Sibelius to sort that stuff out for me (I don't recall bracketing rules being part of the ABRSM theory syllabus in the UK).

Since MuseScore's users skew young, this is the kind of thing we should do for them. In addition, we should be arranging the instruments into a conventional ordering too and automatically resizing the page and staff sizes accordingly. I'm constantly seeing users working on default scores without any bracketing, which makes them look a little ugly and amateurish. Moreover, it's a pain to have to keep setting up brackets if you create scores regularly.

Lastly, think about someone coming from Finale, Dorico or Sibelius: what is their first impression going to be, when they see instruments falling off the page, with no bracketing? It's going to be the same as my first impression: that MuseScore isn't a serious piece of software.

Yep. And we should make it easier to edit them too. I really like the Dorico defaults. I'd love to come up with a system that exposes them in a way that isn't too cluttered.

That all makes sense. We go to the trouble of providing so many templates to help solve those same problems, but lots of people skip them, and just create scores from scratch - or, worse, start with the default untitled score and add to it. When you mention "instruments falling off the page", I guess you mean the fact that we don't automatically increase page size or decrease staff size to fit as many instruments as you like. That's definitely worth finding a good solution for, but emphasis on "good" - merely reducing staff size to still fit everything on A4 or Letter is not good. But there are other issues open for that, other places to have discussions on the "create new score" experience.

For now, though, to me it is still worth thinking about whether there is a "quick fix" here that would not be a problem to incorporate into a grander future design. I still kind of think a bracket property would be the most flexible and easiest to implement short term. I also think it would be quite likely to be something that could be incorporated into future designs for the "create new score" wizard - the wizard would know to set the flag one way by default for wind, brass, or string sections, the other way for choral sections, lead sheet type layouts, etc.

My sense is a property set on the bracket that defaults to the way it is now ("show if only one staff = false") would not create any serious compatibility issues. Existing scores would load the same. If a user explicitly sets the bracket property to "show if only one staff = true", he gets the result he wants as long as he doesn't try to load into an older version. If he does load into an older version, the option is ignored, and he gets the current behavior, which isn't the end of the world.

So to me, still something to consider.

One clarification: I’m talking about defaults rather than templates. I think people are most likely going to start from scratch as you say. Telemetry should help us figure out how many people use templates once it has had a bit more time to collect info.

Fixed in branch master, commit 306bdf8178

fix #296075: enable showing brackets which span to single stave when empty staves are hidden

Fixed in branch master, commit 2d22f00e74

_Merge pull request #5996 from Howard-C/show-brackets

fix #296075: enable showing brackets which span to single stave when empty staves are hidden_

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