Insert measure at beginning of system generates extra undeletable key signature.

• Jan 31, 2019 - 11:34
Reported version
3.0
Priority
P1 - High
Type
Functional
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
MuseScore

(1) Create a new score with a key signature other than C major.
(2) Insert one measure while the first bar of the second row of staff is active.
(3) Insert one measure anywhere on the first row of staff. *

*If there are notes on the staff, more measures may need to be inserted in (3), in order to make a measure move to the row underneath, and cause the problem.

The key signature is repeated on the second measure of the second row of staff. The same thing occurs if you do the same steps on any rows of staff next to each other.

Comments

• Mar 3, 2019 - 17:34
Title Inserting measure(s) creates unnecessary key signature repeat in staff underneath. ⇒ Insert measure at beginning of system generates extra undeletable key signature.
Severity S4 - Minor ⇒ S3 - Major
Priority ⇒ P1 - High

Confirmed. We found and fixed a number of similar issues, but somehow this case still is broken.

Goes away on save/reload.

Reply

• Mar 16, 2019 - 16:04

I've found the cause, not sure what the best solution is.

When inserting a measure in front of one that has a header (clef/key/time signature), we move those elements to the newly inserted measure, but we don't actually mark the new segment as a header. Thus, they don't get automatically removed if the layout changes and the measure no longer is at the beginning of a system and thus no longer requires a header. removeSystemHeader skips segments not actually marked as headers.

The two solutions I can see are either make sure we mark the new segment as a header if the old one was, or don't actually bother generated elements at all since the layout takes care of removing and creating new headers and trailers as necessary. Either solution is very simple, but also a little scary in that there are so many different cases to make sure we don't break along the way.

I'm leaning toward the "don't bother moving generated elements at all" approach, FWIW, as it seems unnecessary to be fiddling with the flags on segments that very possibly are going to be removed anyhow during this very same operation, as the inserted measure may end up fitting on the previous system.

I should also note we have still a few lingering reports of doubled time signatures, and in these cases, it seems somehow a courtesy time signature gets "stuck" at the end of a measure in the same kind of way as we are seeing here. It seems at least possible that a similar thing is going on - some operation results in a courtesy time signature segment not being marked as a trailer and thus not being removed when it should be. Unfortunately, we don't have steps to reproduce this, just a couple of scores that have these already present. The fact that the extra time signature was actually written to the file perhaps suggests there something different going on (the key signatures here don't get written because they are still marked "generated").

Reply

Fix version
3.1.0