Instrument labels incorrectly placed after hide empty staves is unchecked

• Mar 28, 2014 - 19:12
Reported version
2.1
Type
Functional
Severity
3
Status
active
Project

OS - Windows 7
MuseScore revision - ea0cfcc

Steps taken to reproduce:

1. Open the attached score.
2. Open Style/General...
3. Check hide empty staves
4. Uncheck don't hide empty staves in first system
5. Click apply.
6. Uncheck hide empty staves.
7. Click apply.

Result: Instrument labels of staves that reappeared are placed incorrectly.
Expected: Instrument labels show up in the same place as from before hiding the staves.

Closing the dialog with OK, or Cancel moves the instrument labels back in the correct place.


Comments

Well, that other issue shows far worse problems than this as well, but those appear fixed.

The layout issue here also occurs if you simply press OK (no Apply), but it goes away on the next layout operation - eg, an edit to the score or even just Ctrl+A. So definitely minor, but of course, still worth fixing.

I'm not positive, but I think the problem is that the text for the instrument name is updated before there has actually been a doLayout() to bring the staff back, so the layout of the text is based on bad information about the system & staff position.

FWIW, I can fix the problem by simply forcing a second Score::doLayout() at the edit of EditStyle::apply(). But that's overkill of course. Even if we did decide to go with this type of approach, it could presumably just be a relayout of the intrument names, and only if there was a change to one of the settings involved with hide empty staves.

Severity

Any luck with a fix, or a work-around, for the instrument name alignment issue?

I can normally correct any mis-alignment by selecting Staff Properties for any stave, clicking "Apply", and exiting Staff Properties. But in the attached, that doesn't work. Some instrument names re-align properly, and others that were previously OK become mis-aligned.

FYI The score is very large and pushes the limits of my PC, which has a pretty powerful processor. The relayout following an edit can be 5 to 10 seconds, and occasionally the screen goes white for a few seconds. (Can't wait for MS 3.0!).
FYI.2 I don't think this score could have been done in MS 2.02. Despite the long relayout time, the score has never "crashed". There would have been too many crashes and hang-ups to do it in MS 2.02.

Thanks,

Attachment Size
Die Walküre- Leb' wohl!.mscz 256.68 KB

The problem being discussed is just a tempoorary visual glitch that fixes itself as soon as the score is laid out again for any reason. IfSo no special workaround is actually needed - just wait and it fixes itself as soon as you do something (Ctrl+A if you can't think of anything else you need to do). If you are seeing something other than that, it's a separate issue, so please file it with the score and precise steps to reproduce. But in your score here, if I toggle Hide empty staves, the alignment is off but fixes itself on relayout as normal.

I think it's acceptable (if not optimal) as is, thanks for the advice.
When the score is initially opened, the alignment is good. So for publishing or printing purposes, I just need to include that step in my work flow, and otherwise not bother correcting it when not pertinent.
FYI I try to avoid toggling Hide empty staves more than necessary, since that seems to be related to the issue of hairpins getting mis-placed (probably due to the re-pagination). So far I've been able to avoid that problem in this score, mainly by moving the other element when there's a collision with a hairpin (or the new dim./cresc. line) instead of moving the hairpin. Also, when the source document shows a hairpin not starting or stopping directly on a note (like in the middle of a measure containing a single whole note), I place invisible rests in an unused voice, and attach the hairpin to the invisible rests.
Some of the hairpins will eventually have to be moved due to collisions, but I will make that the very last step in finalizing the engraving.

Again, thanks!