Insert measure leaves clefs

I see what you mean. This is a result of selecting the first measure and pressing insert:

Add/Del measures at the beginning of a piece has never, IMO, done the right thing, i.e., mantain the clefs, time signature, key signature, any tempo indication (tricky).

I cannot reproduce with a new score or any of the half dozen or so existing scores I just tried. Can someone attach a score that demonstrates the problem for them? My guess is, maybe the problem only exists for scores imported from 2.x with the first beta then saved.

String quartet workspace.mscz

This was created in the nightly I was using on December 2. It was probably 2e2af50, at least that's what's in the score properties. I created it using Save selection from a score I created with the same nightly that was made with the String Quartet template.

2e2af50 can't really be, it is just 2 days old

The file was still created on 2 December. I didn't look up the date of the build, just what the score said was the build number. Unless I found a score I uploaded on 2 Dec I have no idea which build I used. None of the scores on my computer have a modified date of 1 or 2 Dec.

Created maybe but definitely not last saved, unless you have a DeLorean and a flux compensator ;-)

The issue with this particular score seems to be the clef used in the bottom staff, which differs from the default for the instrument and is hence inserted as a "mid measure" clef. As such, it is at least somewhat correct that it remain in that measure if you insert another before it. Of course, that doesn't excuse the clefs on the other staves, nor the fact you apparently cannot delete them, but the question is, how exactly did the score get this way? Steps to reproduce from scratch would help.

The question of dates and versions is relevant, since December 2 suggests this might have been with beta 1 which had known issues with clefs, particular when importing from 2.x (was that the case here)?

Could also be something specific to "save selection" although it's an uncommon feature and it seems somewhat unlikely the OP was using it.

The non-deletability of the extra clefs probably relates to #279609: Inserting measure before measure previously at start of system displays spurious key signature. That issue is about key signatures, but in principle the same underlying issue of disabled segments needing to be handled properly applies to clefs as well.

Anyhow, if this is just a corner case most people won't run into- which right now seems to be the case - then this is not as critical as it might appear at first. Especially since the workaround is simple.

I'm not sure how it got to this state, but it did. As I previously said, the score was originally created using a version 3 nightly on Dec 1 (I've never downloaded a version 3 beta) using the string quartet template. I then used Save Selection on several empty measures to create a clone of that score to work with. The Dec 1 date is the date created that is reported by Windows.

Sure, I get that. FWIW, a nightly from December 1 would be essentially the same as beta 1 and have the same bugs, so I was trying to understand if that is what we were seeing or not.

Answer: it is not, I can reproduce from scratch:

1) new score for flute and oboe
2) add "alto" clef to first bar of oboe part
3) save
4) close
5) reload
6) select first measure
7) insert measure

Result: same as shown

So the issue happens any time a new clef is added at the beginning of a score and then you save and reload it. If you try inserting before the save and reload, you simply lose the new clef, which is bad too although maybe not as bad.

I'm leaving P0 since it will come up and is fairly difficult to work around (solution seems to be to delete the bar, then you can insert as many new ones as you like, and then re-add the clef).

Some insight into why this happens:

The initial clef segment contains all four clefs. The bottom one - the one changed from the default - is marked not generated, the others are marked generated. When you insert a measure, we simply keep this segment, including the generated clefs. What we should do, I think, is remove generated clefs from this segment when inserting measures. And, probably, notice the one non-generated clef and remove it as well but then reapply it to the first measure. Pretty sure we did something like that in 2.x

This PR should fix this: https://github.com/musescore/MuseScore/pull/4453.

Fixed in branch master, commit 1eecf01ebb

fix #280092: move clef properly on inserting measure to score start

Fixed in branch master, commit ec2e979e30

Merge pull request #4453 from dmitrio95/clefs-issues

fix #280092, fix #279183, fix #279676: clefs-related issues

Automatically closed -- issue fixed for 2 weeks with no activity.