Clef change on first note of system not inserted as mid-measure change if no key signature present

• Jan 30, 2015 - 20:54
Type
Functional
Severity
S4 - Minor
Status
active
Project

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.


Comments

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: on ceb2a50 July 25.jpg

-With this Nightly/commit mentionned above: f97a8b2
I get: on f97a8b2 July 25.jpg

- 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.

Title Clef change on first note of system inserted as mid-measure change if key signature present Clef change on first note of system not inserted as mid-measure change if no key signature present
Status (old) active patch (code needs review)

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).

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.