The clef is not replaced, but added on the clef change

• Jan 13, 2023 - 13:25
Reported version
4.0
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
needs info
Regression
No
Workaround
Yes
Project
  1. Add clef change to the staff
  2. brake the system
  3. change clef to another
Attachment Size
2.png 41.13 KB
1.png 41.28 KB

Comments

Seems, that not. But this is also not 100% reproducible: in that case, I mentioned it's 100%. But, in my score I couldn't make it disappear until copied everything, erased and pasted again.
So, probably, there is something in, that is not counted in exchange buffer, but present in the real project.

Attachment Size
1.png 57.84 KB
Workaround No Yes

even if there's a workaround (which in this case rather is the fix, resp. the better way to notate this anyhow, including the courtesy clef at the end of the previous system)

Reproducibility Randomly Always
Status needs info active

I am afraid, that already replaced it by the clean (repaired) version... Even one in .msbackup folder. But if it helps...

Attachment Size
February.mscz 48 KB

The workaround is to cut\paste the whole score in place. I'm not sure if it leads to avoiding problems with particular moments, when two clefs are assigned to the same note (not to the measure). But it definitely helps in the case when, at least graphically, there is no clef, that produces the bug.

Also, if it helps — the last time I couldn't resolve this conflict in place (https://musescore.org/en/node/342147#comment-1165682) — I applied the clef to the range of the whole bar. It places the clef at the beginning of the range, but not on the end of the measure. Then, when I added clef to the next measure — it was doubled.

Status active needs info

I can reproduce a colission of the clef with the key signature (and IIRC that is a known issue), but not with the other clef