Clef on first note of system becomes header clef after save and reload

It worked in 13, and my guess is it probably worked until this summer, when I see a series of changes to this part of the code (Score::cmdInsertClef(Clef*, ChordRest*) in cmd.cpp) - including one bug fix by me. Should be straightforward to fix, and I can look at this tomorrow if no one else gets it first.

Ooops, sorry, didn't see your post, cadiz1 - I still had the older version of the thread up in my browser window. Anyhow, that pretty much confirms the issue is related to thsoe changes. Looks to be an easy fix.

To be clear, though - you *do* get a courtesy clef if you create a "normal" clef change: one where you add the clef to the measure itself, not the note (or apply the clef change to the existing clef). Only the special case where you try to apply the clef change to the first note of the measure fails, and only if there is a key signature. Normally, apply clefs to notes is how you apply *mid-measure* clef changes, and that's what's actually happening here as well. It's just that normally the code automatically detects a "mid-measure" clef change at the beginning of a measure and converts it into a "regular" clef change for you, but it fails in this particular case.

I'm having second thoughts about this. Instead of "fixing" the case where there is a key signature so it converts the clef change from a mi-measure change into a "regular" change, I'm now inclined to simply disable the code to convert mid-measure clefs on the first CR into "regular" clef changes. The original thinking was presumably that there was no reason for such changes to exist. At least, that's what I must have been thinking when I filed #28996: No courtesy clef created when adding clef to first note of system. But I was wrong. Mid-measure-type clef changes at the beginning of a bar are used for cues. So we should keep this behavior, and change the no-key-signature case to work the way it currently does when there is a key signature.

PR submitted:

https://github.com/musescore/MuseScore/pull/1712

As explained in the comments, I have reservations. I actually implemented both fixes - *always* moving all clef changes on the first chordrest of a measure to the end of the previous measure, or *never* (as opposed to now, when it sometimes does, sometimes does not). A single line of the code controls which behavior is used. So regardless of which way we decide to go, we can use my code if desired. But I am a bit concerned about possible interactions with #23254: Layout / undo issues with clef change after repeat barline (and to a lesser extent, #46106: Undo of insert first measure corrupts clefs).

Apparently this does not survive save/reload - again, only for C major. See https://musescore.org/en/comment/reply/70991

I may look at this, but probably won't any time particularly soon, so I'm unassigning myself.

Interesting, it appears it works after a second attempt - after the initial save/reload converts the mid-measure clef to a standard one, if you then fix it all; up again and save again, it works.