Changes in clef and key signature on save/reload with system changes involved
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
1) Create piano score with four measures
2) Change barline at end of second measure to an End-Start Repeat
3) Select third measure in bass, and set treble clef
Note that the clef is now inserted between an End Repeat and a Start Repeat barline. This result is hidden if the end-start falls at the end of a line, as it just looks like a courtesy clef.
Functional work-around is to place the clef before the first note of the measure, although this may not be as desirable as having it appear before the measure.
HOWEVER, if the score is uploaded to musescore.com then a clef before the first note is treated the same as a clef before the measure. See for example. measure 10 of https://musescore.com/user/4151271/scores/6575333
| Attachment | Size |
|---|---|
| clef change before end-start barline.mscz | 22.28 KB |
| clef change before end-start barline.jpg | 94.51 KB |
Comments
This is correct behavior in most cases - the clef is not changing twice, only once, so it doesn't belong within the repeats. However, your first example does involve the clef changing twice, so the way you have it notated there is proper - clef within the repeated section.
It would be good to someday provide more direct control of all the various possibilities that exist.
This particular score does behave quite stange though, in 3.6. try applying the clef change to the first note of these measures, remove the other 'measure' clef changes. Apply less stretch, as much as you can, save, close, reopen, wonder...
To me that looks like a pretty bad bug?
You mean the fact that the clef moves to before the barline? I think that is probably related if not identical to #46036: Clef on first note of system becomes header clef after save and reload. But I also see an extra key signature, not sure what's about. Proably also related to the fact that the measure is briefly moved to the next system where it does need the key. Probably the clef bug triggers the key signatures also by marking the measure as a header but then not and signals get all crossed up.
yes, both