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

• Oct 25, 2019 - 06:40
Reported version
P1 - High
S3 - Major

Open the score and tick "Hide empty staves".
On the second page, there's two woodwinds, one brass and one pitched percussion. The woodwinds have their bracket, while the brass and the percussion doesn't.
I consider this "critical" because there's no workaround, and it violates the principle of orchestral music notation.

This problem is very similar to #290409: Stave brackets disappear on a 1 line percussion staff but has no relation to it, as all staves shown here are not 1-line.

Attachment Size
Untitled-2.mscz 13.01 KB


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.

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.

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 starting on page 17. I believe the PDF is too large to attach so you can download it yourself from 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.

@Jojo-Schmitz, MuseScore 2 has the same behaviour. And yes, rendering differently all of a sudden should be avoided, but maybe if the change is implemented in 4.0, a message box can be shown asking whether or not render a score from MuseScore 3 with MuseScore 4 layout, just like automatic placement of scores from MuseScore 2?

@Marc Sabatella, I agree that the old scores should not be screwed up, but "That's not necessarily to say it can't be different for new scores, though" confuses me: do you agree to implement this change (for future scores) or not? You used a very soft tune but what's really useful is a firm stand. If you agree, then the suggestion gets one upvote; if you don't, then one downvote. If you were hesitating, it's OK, but I can really use some clear standpoints.

And this isn't anything about parts. Parts with one instrument each show no brackets, and that's fine, this isn't, and won't be affected by changes of layout of the full score. The only divergence we have is the brackets in the full score, if only one instrument remains out of the bracketed instruments in a certain system, whether we should bracket it.

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.

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.

In reply to by Marc Sabatella

My personal perference is that there is a bracket even if there's only one stave on full score, but not on parts. I think we can differentiate the style of full score and parts and make the styles both customizable.

OK, maybe we shouldn't focus too much on the default, because it seems only a few like me want the opposite way and the majority still stand for the current style, so I agree that the default can remain what it is. But at least there should be an option, a stave property at best, for the full score. Maybe there can be a score style setting too, so I won't have to customize all the staves one by one, and the stave property overrides the overall style.

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.

In reply to by Howard-C

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.

In reply to by Marc Sabatella

OK, I'll list some reasons why I feel it necessary to implement the original idea in 3.3.x or 3.4:

(1) The issue #296075 we are discussing here has no workaround. There are a lot of scores which do have brackets spanned only to one stave, and MuseScore simply doesn't support that. You don't see the problem so critical probably because you rarely write orchestral scores, but for the users, including me, who write them quite often, it can be a great pain.

Apart from not perfect, the bracket system in MuseScore 3 is also problematic. With this problem, full orchestral scores produced by MuseScore 3 are far less beautiful than published scores which meet the standard. I can give you an example:

批注 2019-10-29 235056.png
(the violin solo has bracket because it occupies a separated bracket right from the beginning, but F Hn. 1 2 shares the same bracket with other brass instruments)

Just look at the absence of bracket beside F Hn. 1 2. I will not be surprised if some publisher rejects the score to be published simply because of it.

(2) Mike's idea is effective, but it's also complicated. Even if it is implemented not long afterwards, there's still too much testing and reviewing required. Which leads to the next one:

(3) We are still in the phase of improving MuseScore 3, not re-designing for MuseScore 4. There're already plans for 3.3.1 and 3.4 as seen on GitHub, and these versions will probably still take months to be released. I'm not saying that we shouldn't consider re-designing, but right now a few improvements, especially vital ("critical") ones, are more necessary than that. Especially when the problem blocks a score from reaching the criterion of actual production.

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.

In reply to by Marc Sabatella

I cannot agree more with your suggestion. Further thinking, the numeric box seems to best fit to be placed in Style->Score, beneath "Hide empty staves within systems", disabled if hide empty staves is unticked.

I was indeed being absolute, but it's probably still not "most publishers" dealing in non-condensed scores: almost all scores used for selling a composition, studying orchestration/conducting and some scores used by conductors during performance are still condensed.

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.

In reply to by Jojo-Schmitz

Yes, because:
- We haven't seen a score which uses different style towards different staves;
- Bracket is something outside the staff itself, so it's weird to have its settings in the staff's properties;
- Even if the user intends to have staves of different style, a workaround guarantees that, which is setting bms to 1 and set unwanted brackets to invisible.

Title Hide empty staves also hide brackets which span only to 1 stave by force Allow user to choose whether or not hide brackets which span to a single staff when empty staves are hidden

In reply to by Howard-C

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

In reply to by Tantacrul

> 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?

Probably not the square brackets, but definitely the "bracket" brackets.

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.

In reply to by Marc Sabatella

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.

In reply to by Tantacrul

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.

Attachment Size
Example_01.jpg 70.9 KB
Example_02.jpg 66.34 KB
Example_03.jpg 137.87 KB

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.

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

Oh, so you agree with me then (laugh)

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.

Yes, I'm now more inclined to withdraw my objection (because it hasn't been taking us any further). If my withdrawing can let us have the tickbox faster, I can do that.

But I'm still curious, have you provided any documented evidence that shows not displaying single-stave brackets is the best move for the majority cases?

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.

In reply to by Marc Sabatella

> 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

We won't want that to happen to MuseScore, right? So if there're enough good reasons to change the default, better do it quickly before more scores are created.

Let's just stop here before more and more points are made. These points only make things more complex. As a matter of fact, I'd like to have a tickbox a thousand times more than a different default value that suits my personal needs. So if the majority of people still rely heavily on the current default, I won't try to go in your way anymore.

In reply to by Howard-C

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.

In reply to by Howard-C

"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 :)

In reply to by Tantacrul

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.

In reply to by Marc Sabatella

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.

Attachment Size
Dorico.jpg 135.8 KB

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.

In reply to by Marc Sabatella

The scores I use most often have brackets for timpani. So indeed it's not universal.

Meanwhile, I want to purpose a "closed orchestral" template, which combines two of the same instruments into one stave (besides Violin I & Violin II), like Flutes 1 & 2; Oboes 1 & 2; ... The lack of this kind of template is the only reason why I don't use the existing template and always create my scores from scratch.

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

Automatically applying brackets can be even more frustrating for users who don't like the bracketing style. For example, in some orchestral scores, all instruments are bracketed in a single big bracket. There're other uncommon bracketing styles as well. We can of course add an option of "Automatically generate brackets" or even create another dialogue for customizing bracket generation, but I don't know why we should go into such trouble while manually adding brackets even for large orchestral scores takes no more than half a minute.

@Marc Sabatella, I just looked into the code and found out the connection between layout and bracket property isn't hard to realize too. So I agree with both score property and bracket property. However I want to wait till the new inspector is ready to implement this ;-)

In reply to by Howard-C

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

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

In reply to by Marc Sabatella

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

In reply to by Tantacrul

Ah, I have the same feelings actually about new users not using brackets and proper order of instruments. If the automatic staff is something we can achieve, it's definitely an improvement. Except for two points: there should always be options to deactivate automatic formatting, and the formatting should only take place after creation (not after modification).

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.

Status active PR created

See The idea of bracket property cannot work well, at least not under the current framework, because basically the brackets are re-created with default properties on system layout. Maybe it has to be a staff property. But I don't see an urgent need. If at certain places, users want to make some brackets invisible, they can always set them invisible (pressing V).

Fix version