Permanent double time signature/key signature after style changed then save/reload

• Mar 27, 2019 - 13:12
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

3.0.5/Windows 7/10

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.

To reproduce:

  • First scenario

    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
    4) Save/Exit/Reload
    5) Press "M"
    6) Cut the system break

Result: double time signature ( test file result.mscz )
time sig.jpg

  • 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

Comments

• Mar 27, 2019 - 13:22
  • Other interesting scenario:

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)

scaling.jpg

Reply

• Mar 27, 2019 - 13:51
Priority ⇒ P0 - Critical

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.

Reply

• Mar 27, 2019 - 18:16

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.

Reply

• Mar 27, 2019 - 18:29
Title Permanent double time signature after saving, deletion system/page breaks or scaling change, and mm rests ⇒ Permanent double time signature/key signature after saving, deletion system/page breaks or scaling change, and mm rests

Okay, I hadn't taken the time to check that out yet. Not really a surprise.

Reply

• Mar 27, 2019 - 21:46
Title Permanent double time signature/key signature after saving, deletion system/page breaks or scaling change, and mm rests ⇒ Permanent double time signature/key signature after style changed then save/reload

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.

Reply

Fix version
3.1.0