Clef changes on a single part makes clefs appear on all parts

• Jan 14, 2021 - 02:28
Reported version
3.5
Type
Ergonomical (UX)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Randomly
Status
needs info
Regression
No
Workaround
Yes
Project
  1. Open new score with 2 or more parts.
  2. change the clef on 1 part.
  3. Save, close and reopen score.
Attachment Size
20_more_mins_of_music_for_spa_ost.mscx 1.33 MB

Comments

It's possible there is a bug that depends on exactly where you change the clef (at the beginning? mid-measure somewhere? between measures?) and exactly how you apply the change (drag and drop to a note vs a measure, click palette with note vs measure selected). So be sure to give us more details.

In reply to by Jojo-Schmitz

Hi, sorry for being vague. I uploaded before and after saving and reloading the score. Before, the viola clef (treble) was small, indicating the clef change, but after I saved and reloaded the score, the clef became normal size. After I pressed "save" (ctrl+s) clefs and and key signatures appeared for every instrument. I'm not sure if this is intentional (?) but if it is is there a way to disable it? Thanks.

I've included two images, before and after (respectively) saving, reopening and saving again. I also Included a video of the incident. Hope this helps.

I still don't understand the exact steps to reproduce the problem:

1) open the score
2) go to measure 31
3) ????
4) save
5) reload
6) go back to measure 31

What's the missing step here?

One thing I can say is that right now, this score is a little messed up, in ways that are definitely known to happen occasionally. The clef that is there now is of the wrong type. Normally, clefs changes within measures should be small, but these should be pretty uncommon. The more normal type of clef change happens before a measure, and is also small. Full size clefs should only appear in the system header - at the beginning of a line of music. But there have definitely been bugs in the past where clefs get converted from one type to another on save. See for example #46036: Clef on first note of system becomes header clef after save and reload, which was reported (by me!) five years ago and has been partially fixed at least a couple of times but problems still remain. So I'm guessing something like that happened here, or perhaps some other similar bug involving flipping between continuous and page views.

In any case, now that the score is in this state, bad things can happen indeed. We'd want to know more about how it happened, so if it's possible to trace your steps back and figure out how to reproduce this a point before any clef is added, that would be fantastic.

Meanwhile, solution to fix this score is to delete this clef and then add it back properly. In this case, that means apply it to the measure as a whole, not to the first note (it should appear small and before the barline).