Instrument name gone when switching order of staves with "Hide empty staves" enabled
To reproduce:
1. In the New Score Wizard, add at least two instruments. To one of the instruments, add another staff. Click "Finish."
2. Add one or more notes to the first measure of the instrument with one staff, and to the first measure of the first staff of the instrument with two staves.
3. In the General Style window, check "Hide empty staves" and uncheck "Don't hide empty staves in first system." Click OK.
4. Go to the Instruments list, and switch the order of the two staves belonging to the one instrument.
Result: the instrument name disappears. It's not made invisible. It's not deleted—according to Staff Properties, it should still be there. It's simply gone, and there's no way to recreate it.
This is currently causing me a huge headache because I'm on a deadline. If this could be fixed within the next two hours or so, that would be great.
Comments
See #30971: Instrument name of multi-stave entry doesn't appear with hide empty staves and if top staff is hidden. I'm not convinced this is a bug. When an instrument has two staves, it is the top staff's name that gets used. So simply add a name to the top staff.
EDIT: ok, it's not thast simple, still looking...
Ultimately, it could be nice to have some way of attaching a name to the instrument as a whole instead of using the top staff name, or of deciding how to handle cases where both staves have names and figuring out which one to use when. But that's not likely in the next two hours.
Right, it's not that simple at all. If it were, it wouldn't be such a huge headache. ;-) I think it makes more sense to mark the other issue as the duplicate and this one as active, because the discussion on that one seemed to miss the point—not even any discussion as to how the situation arose.
My impractical short-term solution is to use a large number of precisely positioned and sized Staff Texts, to make the score look all right for now.
If you want to categorize this as "major", it will help to post the score you are having problems with and explain why you think this will come up more than rarely, and why simy not hiding the staff or changing which one you put the content in isn't a reaosnable workaround. To me, this seems a very esoteric use case.
I'm not going to post the score just yet (it's just about complete, and I'd have to get the permission of a collaborator), but it's simple to describe. This is a very large score. At one point, in one instrument, there is a solo, while the rest of the section continues to play in the background. Naturally, the way to notate this is to have the instrument temporarily split into two staves. In order to achieve this effect, you add another stave to the instrument, fill in the solo section, and then hide empty staves. No problem here—except that I added the solo to the lower staff, instead of the upper, and then wanted to change it. The way to change it is obvious—switch the order of the staves. And then this bizarre issue arises. I'd say this is an expected feature that's definitely not working the way it's supposed to, and the fact that there is no apparent workaround to get the instrument name back clinches it as "major."
There are at least two very simple workarounds, if I understand the situation
1) When choosing to use the hide empty staves option on an instrument with multiple staves, always have it be the top staff that has the content. This should work just fine.
or
2) Don't use two staves in a single instrument, but instead, use two instruments. The ability to hide a single staff of a multi-staff instrument wasn't even supported until 2.0; this is the method people used successfully for years with 1.X. There's really no special advantage to the way you chose to do it.
Anyhow, I'm not going to play games with categorization, but this is *not* the sort of thing I had in mind when I pushed for the introduction of the "major" category.
This is not major.
I guess I just don't understand the difference between "This is just a normal, regular old bug" and "This is a pretty big one" and "This is of critical importance." I have a very hard time understanding why, for example, #57646: Segment-attached element in Voice 2 causes corruption in Voice 1 on copy and paste is critical, and this isn't even major—to me they're basically on the same level, especially because they're so easy to compare.
However, I only reversed Marc Sabatella's initial priority downgrade because I thought he had done it while under a misapprehension, before his "EDIT: ok, it's not thast simple, still looking...". I won't argue about it. I only hope that this bug can still be fixed, even if it isn't major.
To me it's a very clear difference. That other bug corrupts your score. If you don't notice it right away, your score is corrupt, and depending on what you do afterwards - eg, trying to copy & paste the corrupted passage - you might make things worse and worse to the point where your score is ruined beyond repair. That's why corruptions are inherently major or critical - they are actually *destorying* a portion of your score, and once corrupted, there is the very real danger that your entire score will be irreparably destroyed. Potentially hours / days / weeks / months of work could be lsot forver. We take corruption *very* seriously because it *is* serious.
In this case here, there is no corruption whatsoever. You just don't see the instrument name when using a certain unusual combination of options. And its trivial to work around as I explained. Nothing is ever lost, there is no danger of *ever* losing anything. It's just a very simple case of "oh, this unusual thing I tried to do didn't quite work, I guess I'll have to do it a slightly different way".
Night and day difference between potential losing many hours of work versus needing to spend a few seconds on a simple detour.
wrong thread... sorry...
Related to #285237: [EPIC] Invisible staves issues
Something missing, no workaround... Why not major :P
The workaround to this particular is simple, if you change the order of the staves, change which staff has the name. That is, this particular is only
About what happens when changing the order of the staves (an unusual occurrence), and has an easy workaround. It’s not major, it’s not even a big really. The more serious issue is #121416: Show instrument name on lower staff when upper staff of multi-staff instrument is empty and hidden, which should not have been closed as it is not a duplicate of this much more minor/non issue.
There is no "change which staff has the name"—according to Staff Properties, it still has it. Think divisi. It's one instrument with two staves.
Indeed, in the dialog it is listed as a part property rather than a staff property, and at least as far as the data structure is concerned, it is even implemented that way. But as far as far as the behavior is concerned, it acts like a staff property on the top staff only. What I am saying is, that's the bug. It should apply to the instrument and not just the top staff, but it really does apply to the top staff only. You don't need to change staff order in order to see the issue. Just create a score such that the bottom staff is hidden on one system and the top staff is hidden on another. You'll see no staff name when the top staff is hidden, thus showing that in effect, we're treating this as a staff property on the top staff not as a part property.
So to me, there is nothing specifically wrong with the staff reordering command, this is really a duplicate of #121416: Show instrument name on lower staff when upper staff of multi-staff instrument is empty and hidden, with the behavior on reorder merely a side effect of the real issue: the fact that the name is in some way being associated with the top staff and not with the part. Which is to say, again, once that other more fundamental problem is fixed, so will the special case of staff reordering describe here. In theory, at least - I'm still leaving this open as a reminder to actually test that case to be sure the fix is sufficiently complete to cover this.