if insert new clef to a measure that already has clef at *start* of measure, then old clef shouldn't remain

• Sep 6, 2015 - 10:27
Reported version
3.x-dev
Type
Functional
Severity
S4 - Minor
Status
needs info
Regression
No
Workaround
No
Project

E.g. attached test-drag-clef-to-measure-with-clef-at-start-of-measure.xml has two measures of bass clef, where the bass clef in the second measure is part of

before.png

If drag a treble clef onto the second measure (or if select that *measure* and double click on treble clef from palette), then the result is in current 2.0.2 release and 35b9f49 will still render the old bass clef, even thought the the rest of the score pitches and newline courtesy clefs will reflect the newly inserted treble clef:

after.png

Note how position of the middle C is determined based on the treble clef. Since this old clef at the beginning of meas 2 is being ignored, I think that old clef should be removed from the score. Here is my expected desired behavoir:

desired.png

Note: if joining two scores with, then the resulting album will suffer from this issue, since the first measure of the second movement will have it's clef at the *start* of its first measure.

Also another way to get this behavior is to insert a clef before a measure N, then insert a clef at beginning of a measure N+2, and then delete measure N+1. The result score will have the two clefs side by side before and after the barline, but the clef on the right of the barline is rendered but ignored as far as pitches are concerned, and dragging a new clef to the measure on the right will not get rid of the measure.


Comments

Title if drag new clef to a measure that already has clef at *start* of measure, then old clef shouldn't remain if insert new clef to a measure that already has clef at *start* of measure, then old clef shouldn't remain

changed title to reflect that issue happens either when drag a new clef from palette, or if select entire measure and double click clef from palette.

Reported version 2.1  
Workaround No
Regression No

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.6567, revision: 3c54040

Still active in this nightly.

The bug described in this report does not exist in current master. True, the "mid-measure" clef is not deleted when a new clef is applied to the whole measure, but that is by design. If you want to delete the mid-measure clef, you can do so.

As far as I can tell, the bug is fixed. The title describes an "expected behavior" that I happen to disagree with, which is why I left this open for now. I am curious to know why @geetar resurrected this old issue.

Status active needs info

As far as I can tell, I agree. The bug was the incorrect display of notes after a double clef change (one before the measure, one at the start). We were previously honoring the first of the two rather than the second, which was bad indeed, but I agree it is equally wrong to automatically delete one of the two. Somehow this works in 2.3.2, so one of the various other changes made (you can follow the thread of linked issues and multiple PR's for them) must have taken care of it.

On the other hand, this stuff is tricky enough with the different cases to consider (single measure systems, repeat barlines, line breaks, behavior on save/reload, etc) that I wouldn't be surprised if there isn't some case that still fails in some way. If someone has steps to reproduce an actual problem, please post it, otherwise I think we should close this.