Superfluous/extra clefs and key signatures inserted after color change

• Oct 4, 2016 - 06:50

-- Using MuseScore on Windows 10, versions 2.0.3 and 3 (185f329) --

MuseScore apparently has more serious problems with color manipulation than the inability to change the color of brackets (https://musescore.org/en/node/127131). In both 2.0.3 and 3 nightly, when you change the color of clefs or key signatures the program adds in unnecessary new clefs and key signatures "downstream" from the recolored items.

For example, here are a few bars before recoloring the system's clef and key signature:
Before changing clef color.jpg

and here are the same bars after applying a new color to the clef and key signature at the left side of the system. MuseScore has inserted new, redundant clef and key signature items in the middle of the line (they're the right color, anyway):
After changing clef color.jpg

Note that in the second example I've also changed the colors of the notes, rests, barlines and staff lines, but those changes didn't cause extra items to appear. (You can tell from the picture that this is 2.x, because the ledger lines don't change color when you change the color of the staff lines. That bug has been fixed in 3.)

It may or may not be relevant to mention that I went back to version 1.3 and tried recoloring clefs and key signatures there. It worked fine--no extra markings were added. But when I opened the 1.3 file in 2.0.3, now every staff on every system had an unnecessary extra clef and key signature.

Comments

• Oct 4, 2016 - 14:51

Here are the steps you can follow to reproduce the color-related sorcerer's apprentice problem (using MuseScore 2.0.2 in this case, but this behavior came to my attention on 2.0.3 and 3.x):

1. Open multi-staff, multi-page score. (In my own documents the extra clefs and signatures didn't show up until page 2. For the demonstration, I started with "Reunion" from 1.x and inserted a bunch of measures to give it some length; as it turned out the proliferation of extra items began on this score on page 1.)

2. Right-click on any clef symbol, choose Select->All Similar Elements and then choose new color. I didn't see any problem after this operation in this test score.

3. Right-click on any key signature, choose Select->All Similar Elements, choose a new color, and then stand back. Note that not only has MS inserted a bunch of extra clefs and key signatures in the new color, but now the original ones at beginning of each system have reverted to black:

Reunion after recoloring.jpg

Attachment Size
Reunion repeated (original).mscz 50.71 KB
Reunion repeated (after recoloring clefs and key signatures).mscz 50.66 KB

Reply

• Oct 4, 2016 - 15:13

Doesn't happen here with one of my multi-page, multi-stave scores, I do see it Happening with your Reounion, but I guess that is because of some quires in the file, being an Import from 1.x and not created from scratch in 2.0
For some reason the change Color of key-sigs here results in a different layout, System breaks being in different places, and as a result unwarranted courtesy clefs and -key sigs to show

Reply

• Oct 4, 2016 - 16:01

Along those lines, the original versions of my own scores came from Finale (2016). I exported from Finale to MusicXML and imported that into MuseScore 3 (and later for testing, into MuseScore 2). The results of the import were excellent, as far as I could see, annd things went awry only when I tried changing colors.

Reply

• Feb 15, 2020 - 12:34

Not really willing to post the score and the steps to reproduce are not clear to me. All I can say is that issues with courtesy clefs, time or key signatures happens every time I use Musescore since the past few years. The workaround seems to be to insert enough fresh bars/measures at the start of the score and copy and paste the corrupted bars/measures and then remove them. Sorry I cannot be of any further assistance.

Reply

• Feb 15, 2020 - 14:28

...but I do not know what steps causes this bug; the unnecessary or even double courtesy clefs, time, and key signatures is a bug that is a very typical user-experience of Musescore that's plagued versions 2 and now 3 for years in spite of promises to fix it. But it's free so I guess we're to expect a buggy experience of this otherwise awesome resource.

Reply

• Feb 15, 2020 - 15:57

Even without steps to reproduce the problem, posting one such score with a problem - one actually created using 3.4.2, not one created with an older version that has known bugs - might help us guess at what some of the triggers might be. I've personally never encountered such a problem since we fixed the last known bugs in this around a year ago. But if any remain, I might guess they have to do with some combination of using linked staves/parts plus toggling of multimeasure rests, concert pitch, plus adding or removing horizontal frames or system breaks. Maybe also things like whether there are start repeats or key/time signature changes in the same measure as the clef, or whether any manual adjustments were applied to any of these elements (like the color change discussed here). Would be interesting to see how many of those variables are present in your score or if any other clues present themselves.

Reply

• Jul 23, 2020 - 07:42

I too have uninvited redundant key signatures and clefs that appear in scores. Just now, two appeared in this transcription as I was adding the lyrics. I have 5 other scores open. I closed this score and reopened it without quitting MuseScore and the redundant key signatures and clefs went away. That worked once before in a different score. I'm sorry that the problem is not still here but I attached the score anyway hoping it might be helpful.

Attachment Size
E The_Lotos_Isles.mscz 36.29 KB

Reply

• Jul 23, 2020 - 08:24

Confirmed. This one I guess: #307911: Extra key signatures appear unexpectedly in parts from multi-staff instruments, and fix itself on save/reload

EDIT: @jnurdtcmt/comcast.net
Just one thing please: could you confirm the problem with extra key sigs and clefs from multi-staff instruments (eg, piano) occurs when you create parts ?
Or only (no parts created), or also in the main score? In this case, it would be another issue (related maybe)

Reply

• Jul 23, 2020 - 13:36

I don't see any clefs if I generate parts from this score using 3.5 RC. But also, the OP mentioned using 3.4.2, and the linked issue was not introduced until after that. So whatever might be going on here, I don't think it's related.

So, if it is possible to trigger a problem using this score - using either 3.4.2 or 3.5 RC - could someone post steps to reproduce?

BTW, while the section of code changed by that PR does say in the comments that it handles clefs also, actually it does not seems to be relevant for clefs at all, with or without the PR. Probably it should be, but if so, the only visible problem would be missing clefs changes in parts created from voice 2)

Reply

• Jul 23, 2020 - 14:24

Okay, possibly my bad. I think I saw it this morning, though, but I can't do it again right now. And I can't remember how I would have done it, where, and in what exact sequence. Anyway, the fact that it's resolved on Save/Reload makes it less important, for the moment anyway (and I edit the main issue accordingly).

Reply

• Jul 23, 2020 - 15:38

No worries, and you did a great job of tracking down the original key signatures problem so quickly!

FWIW, there are a couple of real clef changes in this score, so I guess it’s possible you saw those and didn’t realize they were supposed to be there? All the extra key signatures make it hard to really see what is going on.

But also, since the report here was using 3.4.2, and doesn’t mention parts, and there are no parts in the attached score, I’m guessing if there is still a problem here it will turn out to be elsewhere.

Was this score originally created in 3.4.2 or was it by chance begun in earlier version? There were bugs fixed around 3.1 that could possibly explain this. A score created in one of those version can have spurious hidden clefs that appear only later, and that can happen even when editing with 3.4.2 even though the bug that introduced the spurious hidden clefs was fixed already.

Reply

• Jul 23, 2020 - 17:58

After new checks (with R.C.), I must have seen that this morning, or something like that (maybe/probably a few different scenarios).

Steps (with score attached) : E The_Lotos_Isles.mscz

1) Remove the first one staff, trumpet instrument (I had removed it first to concentrate on the multi-staff instrument aspect that came to my mind this morning)
And I'm looking at measure 17

step1.jpg

2) Undo

I receive this now:

step2 after undo.jpg

3) I change the layout, say by adding a system break at measure 6.

4) Undo

And I get this now in measure 17:

step3.jpg

All this without parts, I got the same kind of result in parts by changing the layout, but I don't remember the exact sequence right now.

If I believe the Score properties, the score was created last month, 28/06/2020. However, after 1 or 2 attempts, I can't reproduce from scratch right now, so I don't know what to think about it now.

Reply

• Jul 23, 2020 - 18:26

OK, this I can reproduce. I am guessing it has to do with the following:

  • the clef change is currently not at the beginning of the system, and thus we don't see a key signature or clefs on other staves
  • after removal of the other instrument, the clef change is at the beginning of the system, and thus we do see a key signature, and clefs on other sytaves
  • on undo, the clef change is back to its original location, but somehow the key signature and clefs that were previously generated don't get cleaned up.

Thinking aloud, I think that is because we are getting confused in the process about whether this measure needs a header or not.

But indeed, I can't reproduce from scratch even when I try to make these same conditions hold.

Reply

• Jul 29, 2020 - 21:23

Ok, I can reproduce now from scratch the issue with clefs.

Steps:
1) String quartet template, and system breaks every 4 measures
2) Add a F clef say measure 19 in Viola instrument
Like this:
string2.jpg
3) Save/Quit/Reload
Test file at this step: string quartet.mscz

4) Select measure 18, and press "Enter" to create a new system break
5) An alternative here to get the same result: either simply Undo either right-click a system break (-> all similar elements -> Del)

  • This too resolves itself on Save/Reload

  • The GIF below shows steps 4 and 5 (with Undo)

For the record, this behavior doesn't occur with version 2.3.2 (just checked by curiosity), and the test file for this version: test version 2.mscz

Video_2020-07-29_220421.gif

Reply

• Jul 30, 2020 - 05:39

Confirmed. The key seems to be that you have the add the clef unusually - you have to add it to the first beat of the measure so it appears after the barline, rather than to the measure so it appears before the barline as usual. When added in this way, it gets converted to a full size clef on reload, and that's when the problems start.

So I think this is likely related to #46036: Clef on first note of system becomes header clef after save and reload even though the specific steps are a bit different.

Reply

• Jul 30, 2020 - 06:07

I don't select the measure, but the full rest, then click on the new clef, as I would do when inserting a mid-measure clef. It's the same behavior if I select the first beat (quarter rest/note). No more problems on the 2nd beat of course.
So, if I understand correctly, the problem occurs when a mid-measure clef is inserted on the 1st beat of a particular staff (or on the full rest), and saved/reloaded score.
Then when a system break change is applied exactly there (at the previous measure), a new layout (by removal system breaks, or Undo) lead to this behaviour on the related others staves

Reply

Do you still have an unanswered question? Please log in first to post your question.