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
3.2
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project

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

Comments

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

@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