Permanent double time signature/key signature after style changed then save/reload
Despite the fix of this issue: #279925: Permanent courtesy time sig and key sig before system/page break when toggling in Continuous View and/or Parts, a some such questions have continued to appear in recent weeks in the forums, and in particular related to this display in Page View.
1) Treble score template
2) Change time signature let's say measure 3 (associated with a system break or page break)
(or load the test file at this step: test file.mscz )
3) Press "M" for enable mm rests
5) Press "M"
6) Cut the system break
Result: double time signature ( test file result.mscz )
- Second scenario (but somewhere, it's a duplicate, since no matter if the steps are applied in main score or in a part, or a few parts)
1) Same file, but with part
(or load this file: file test parts.mscz
2) Repeat same steps as before, (#2 to #6), but done in part.
Same result in part: file test parts result part.mscz
- And so, according to different operations of the same type carried out in the main score and in the parts, you can obtain different displays in the main score or/and in one or more parts.
For example in this other test file: various.mscz
1) Load this new test file (basically with same content as before)
file test scaling.mscz
2) Press "M"
3) Format -> Page settings -> Change scaling (staff space) let's say to 1.364mm, instead the default 1.764
Result: a double time signature appears where the time signature was on two systems in the precedent layout ( file test scaling result.mscz )
For check, revert to the initial layout, and try a new one (eg 1.164mm)
Brilliant work, thanks! We had fixed other similar cases over the past few months but we've had enough reports of this that I knew there must be something we missed.
BTW, same result for key signatures, if present along with time signatures.
The problem seems to be that the courtesy time signature segment at the end of the first system is not being marked as "trailer" for the copy in the underlying measure. Multimeasure rests are implemented in two layers - the main mmrest measure and the individual underlying measures beneath it are maintained separately, with things like the time signatures stored in both places. The copy in the mmrest measure in marked generated, but the copy in the underlying measure is not. It's correct when you first create the mmrest, but wrong after save/reload.
In theory, we fix this by getting it right when reading the score. I see the time signature itself isn't marked "generated" either, but that doesn't seem to cause problems, as it's that way before the save/reload as well. Could be related though.
Okay, I hadn't taken the time to check that out yet. Not really a surprise.
I have a fix for this specific case, but I'm looking to see if a somewhat more general fix won't help pre-emptively fix other cases.
What "specific case" are you talking about?
And what you mean by "other cases"?
Warning: you asked :-)
It turns out that this is triggered by any style change, not just mmrests. In other words, if there is a courtesy signature present in the score, you make any style change (toggling mmrests just happens to be one example) then save & reload the score, you'll get the same problem. And it is indeed due to the courtesy signature getting marked "not generated" after the style change. Whenever there is a style change, we update all elements in the entire score to make sure they pick up any changed style settings, and here, it's the act of reapplying the "scale" setting that causes it to get marked not generated - it's the only unique style setting that applies to time signatures only.
So I can special case handling that particular style setting, but what if we later add more style settings for time signatures? What if there are other generated elements with other style settings that would exhibit the same type of issue?
I'd rather be a little smart about how we update elements after making a style change, so we don't inadvertently mark things non-generated. I just need to understand the safest way to do this.
Fixed in branch master, commit f5abd23390
fix #286794: permanent courtesy time signatures after style change
Fixed in branch master, commit 25b69110b7
_Merge pull request #4839 from MarcSabatella/286794-double-timesig
fix #286794: permanent courtesy time signatures after style change_
Automatically closed -- issue fixed for 2 weeks with no activity.
In reply to Auto close by System Message
Seems this is still a problem - I have Musescore version 184.108.40.20678, and test files in the discussion still produce the same double time signature
3.1 won't fix scores that have that issue already, but you can fix those scores there
In reply to 34.1 won't fix scores that… by Jojo-Schmitz
Doesn't seem to. I used the test file with parts, loaded it, hit M, saved and exited, reloaded, hit M again, went to the piano part and deleted the break - and the double time signature popped up again ...
In reply to Doesn't seem to. I used the… by polehamster
... but if I create a new file from scratch in Musescore 220.127.116.1178, rather than use the downloaded file from the thread, the problem does not occur - thanks!