Clef on first note of system becomes header clef after save and reload
S2 - Critical
Ubuntu 14.04, GIT commit: e255575
Reported in http://musescore.org/en/node/46021
1) My First Score, or new from Treble template, key of Bb, 4/4
2) add a single quarter note to measure 5 (first measure of system 2)
3) click note in measure 5
4) double click bass clef icon in palette
Result: clef is added as a mid-measure clef change. The initial treble clef is left intact, and no courtesy clef appears at end of previous system.
There is code to detect an attempt to add a clef change on the first chordrest of a measure, and to convert it from mid-measure to "regular" if so. But this apparently doesn't work at the beginning of the system if there is a key signature there.
I think that this issue is a side effect of this commit on July 25: https://github.com/musescore/MuseScore/commit/f97a8b22c681ee778e725e558…
By memory, it's not the first time that we encounter it.
- With this Nightly: ceb2a50
I receive this:
-With this Nightly/commit mentionned above: f97a8b2
- Note that in the different tests (with previous Nightlies, and next Nigthlies, even recently), I have never seen courtesy clef at end of previous (first) system.
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.
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).
Fixed in ea568fbfef
Automatically closed -- issue fixed for 2 weeks with no activity.
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.
I think this is already fixed. I don't have a problem with this while looking at the three new initial clef bugs.
No, I misread the issue, sorry.
But without courtesy clef.
I notice a change on last February 15 between this commit/nightly: 9e69e33
and this one: 9077881
Maybe related to ? https://github.com/musescore/MuseScore/pull/3694
To fix: #272887: Unable to add mid-measure clef on the first tick of a measure
I want to have a clef before the first note of a bar following an end-start repeat barline, but after saving and closing the work it will re-open showing the clef as a header clef now in between the start and end repeat barlines.
Below is how I would like it to look and this matches the sheet music source I am typesetting.
Below you can see the start-end repeat is now split and the clef is now full size and inbetween the two barlines.
OS: Debian GNU/Linux 9 (stretch), Arch.: x86_64, MuseScore version (64-bit): 3.4.2., revision: 148e43f
Also downloaded the 3.5 BETA Appimage and reproduced what I have described above.
Came up again in https://musescore.org/en/node/318741