Clef change at start of score converted to mid-measure on save/reload with modified system barline

• Jul 30, 2019 - 15:40
Reported version
3.2
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
Yes
Workaround
Yes
Project

I've some scores with 8va treble clefs. It worked perfectly over the last months, but I have some recently created scores where the 8va treble clef is not saved correctly in staffs 2,3 and 4. It's shown correctly after editing (see screenshot), but after closing and re-opening the file it shows a regular treble clef, and a small 8va clef after the time signature.


Comments

Status active needs info

You're using an old version of MuseScore 3.0.5. This has been fixed. Upgrade and the best way to fix this is to reenter them after you upgrade, it will not automatically fix the bad display.

Frequency Many Once
Status active needs info

Did you follow the advice: reenter them after you upgrade, it will not automatically fix the bad display?

Very strange score, claims to be 4 times Horn in Es (Eb), but is non-transposing.
Yet has settings for concert and sounding clef, both G8va, but not for the the instrument itself, instead in the first measure

In reply to by Jojo-Schmitz

Maybe I'm doing something wrong, but it has worked that way for me in the past with Bb and Eb scores. It's for pless and parforce hunting horns. They're both noted in C. I create a new score with the number of instruments, and do adjust the transpose to 0, because it would show sharps otherwise. The pless horns are always in Bb, noted in C. The parforce either in Bb or Eb, also transposed to C, with the 8 below the clef. So i've pulled a clef with 8 from the left on the default clef, then marked all notes for the instrument and moved it back one octave.
Is that not the right approach?

In reply to by Jojo-Schmitz

@Jojo-Schmitz my question was regarding the score with the 8va clef saving issue. I've attached - as requested - the current edited score, edited with 3.2.3, which still shows the problem that should have been fixed.
Regading your inputs for transposing, thanks for the hints, I'll just use C Horns in the future. Thanks a lot. But the issue I was raising this ticket for still persists.

Status needs info active

True. Your changes to transpositoning might contribute to the issue, but this really shouldn't cause this, if dealt with properly in the code I guess.
I don't understand though why it is behaving that way, hopefully someone else find out

Interesting enough I have a similar score started with 3.2.3, where the problem doesn't occur. But same basic setup, 4 Eb Horns, removed transposing, etc.
And I have about 35 scores with Horn in Bb, where the problem didn't occur on 3.0.x nor on 3.2.x.

@Jojo-schmitz: I tried your recommended approach with 4 Eb Horns and using the concert pitch button. Exact same results. A fresh score created on 3.2.
I can "fix" the clefs, but as soon as I reopen the file after writing, it's broken again. I'd happily provide more score files if required. If you suppose that I do something wrong, please provide exact steps how this is assumed to work. But I'd call behaviour buggy if things are not saved and the score looks different after re-opening.

The problem can easily be reproduced:

1) create a new score, instruments do not matter, at least 2, e.g. with voices, keep the other settings at default
2) change the clef to 8va by pulling "treble clef 8va bassa" from the palette to the two existing clefs
3) select all barlines by right click on bar line -> select -> similar objects
4) uncheck and then check the box "span to next barline"

So far everything looks ok, but then:

5) save the file, close it
6) reopen the file
7) watch the broken clefs

So apparently this only triggers if all barlines from the score are being spanned.

I did compare the files before and after step 4), and apparently this causes the problem:

$ diff -u cleftest-broken.mscx cleftest-working.mscx
---- cleftest-broken.mscx 2019-08-05 11:05:54.870446861 +0200
+++ cleftest-working.mscx 2019-08-05 11:01:44.650979075 +0200
@@ -536,8 +536,6 @@
<Staff id="2">
<Measure>
<voice>
- <BarLine>
- </BarLine>
<Clef>
<concertClefType>G8vb</concertClefType>
<transposingClefType>G8vb</transposingClefType>

It doesn't matter if the Barline tag is empty or does contain anything. If it occurs in front of the <Clef>, the problem is triggered. Attaching both files for your reference.

Attachment Size
cleftest-broken.mscx 22.65 KB
cleftest-working.mscx 22.61 KB
Title 8va clef saving issue Clef change at start of score converted to mid-measure on save/reload with modified system barline
Priority P2 - Medium

I was able to reproduce a problem on 3.2.3 following those steps. On reload, the top clef was fine, the bottom had the clef appear as a "mid-measure" clef rather than at the start of the measure.

The problem is indeed likely due to the modified barline. For the record, the process you used to change the barlines is not something one would normally do, for a number of reasons - most importantly, that it only affects the existing barlines. So if you add measures, they won't have their barlines extended. If the goal is to extend the barlines through the scores, simply double-click one then drag it. Or, change the span of one then hit the Save as staff default" button. Then it correctly changes the staff settings rather than the setting of existing barlines individually. The other downside of your approach is that it affects the system barlines but you don't actually want to modify those. And that's what triggered the bug.

Try selecting all barlines again, then pressing Delete, which removes your customizations, then delete the interior clef and re-add it to the beginning. That worked for me and survived save/reload