Key / Time Signature Courtesy option (and delete) ineffective with Multimeasure Rests
Version 2.0.0 revision 6e47f74 - Windows XP 32 bits
Activating or deactivating the key signature courtesy flag in the inspector has no effect when the multimeasure rests is activated in the general style.
See attached file which has been built as follows:
- the multimeasure rests is activated in the general style settings
- the score has a 2-measure rest just after a signature change
- a line break is placed at the signature change
- a double barline with the new key signature is displayed at the end of the line
Selecting the new key signature (bb) on the second line and unchecking the "show courtesy" in the inspector doesn't hide the double barline with the new key signature at the end of the first line, as expected.
Workaround : deactivating the multimeasure rests in the general style allows to hide/display the courtesy key signature as wanted, and then reactivating the multimeasure rests will keep it hidden/displayed.
| Attachment | Size |
|---|---|
| Key Signature Courtesy with Multimeasure Rests.mscz | 5.92 KB |
Comments
Good catch, including finding the workaround! Also, deleting the key signature has no effect if mmrests are enabled.
Similar for time signatures, except deleting works at least.
I'm raising priority as the effects are rather more severe than may have first appeared.
I was thinking at first that these elements should be linked to their counterparts - eg, the keysig in the regular measure to the keysig in the mmrest. But while this allows deleting to work, it still doesn't fix setting properties like SHOW_COURTESY (or VISIBLE). So I tried a different approach - making the act of selecting a keysig or timesig also automatically select its counterpart in an mmrest. This works well enough, but in testing, I discovered another bug:
1) new score, treble clef template, key of C
2) add line break to end of measure four
3) add D major key sig to measure 5
4) press "M" to enable mmrests
5) press "M" again to disable them
6) delete key sig in measure 5
7) press "M" again
Result: a courtesy D major key signature appears at the end of the score. It goes away on reload. Similar story for clef changes.
This problems exists with or without my changes. FWIW, here is the code I was testing, which seems to basically work OK although it isn't really fully tested:
https://github.com/musescore/MuseScore/compare/musescore:master...MarcS…
For the bug described in comment #2 (and 7 steps): very former issue.
![courtesy.jpg]( "courtesy.jpg")
I can reproduce constantly, in particular with this Nightly on May 19: 56177c3
Result:
That's good to know, thanks! How about the original bug? To see that, follow the first 4 steps from comment #2, then try either
5) select and delete the D major key signature in bar 5
or
5) select D major key signature and uncheck "Show courtesy" in Inspector
Were those also present since May? In both cases, the bug is that the operation does not succeed. The key signature is not deleted, or the courtesy key signature at the end of the previous system does not go away.
On 19 may, the key signature is deleted at the "new" step #5, as you see:
![D delete.jpg]( "D delete.jpg")
But the courtesy keysig remains after untick "Show courtesy"
In which way a further investigation could be useful now?
I guess it *would* be useful to know at what point the delete behavior changed to what it is now (that is, at what point did the bug appear).
The fact that the courtesy behavior was broken but delete was working tells me it probably wasn't working the way my current proposed fix works, since both work for me in my proposed fix. Presumably the change that broke delete was made to fix something else, and I'd like to test my proposed fix to make sure I am not now breaking that.
For the "first" issue (deletion of the keysig), it works on May 19 (as said) and fails on ... June 7 :(
I have not intermediate nightlies between these two dates. And as commits with involved key signatures are numerous, it's not easy...
However, I checked. Some proposals, sorry not to be more specific
- https://github.com/musescore/MuseScore/commit/085492df900917117088aa1fd…
- https://github.com/musescore/MuseScore/commit/3ae79f8b3e9f9defd077be6a3…
- https://github.com/musescore/MuseScore/commit/7eca27a6c800a512d888d52ee…
- https://github.com/musescore/MuseScore/commit/7eca27a6c800a512d888d52ee…
- https://github.com/musescore/MuseScore/commit/9a6d909a29d3c98f17f79b33c…
I am actually encountering quite a few problems involving the deletion of key signatures, time signatures, and clefs in the presence of multimeasure rests. To the point where I'm not sure it makes sense to mess with this particular detail until we can take the time to look at the underlying issues. I'm talking about cases where I have a key signature change with mmrests on, then turn mmrests *off*, then delete the key signature, then turn them back *on* and see the key signature gone as expected but the old courtesy key signature still remaining. And miscellaneous variations on this.
I think a good part of what I am seeing is due to us "remembering" the contents of mmrests while they are turned off rather than regenerating them each time they are enabled. Is this merely a performance optimization, or is there some reason we need to do this? Seems it causes more trouble than it's worth.
I should have mentioned this too - #56721: Crash on undo of mmrest with courtesy signature
BTW, see also https://musescore.org/en/node/57801#comment-267166. Time Signature Properties is also ineffective when performed on a time signature in an mmrest. I don't think my proposed change will address this. Even if both versions of the time signature are selected, time signature properties will presumably only affect the one you actually right clicked. So there would need to be special code to deal with this. And maybe that is really the right approach for the other issues too, even though my original proposal is simpler.
Still actual.