Extra initial clef in scores imported from 2.x

• Nov 8, 2018 - 17:59
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore

1) create a score in 2.x using two or more staves (or download the attached)
2) load it into 3.0
3) save
4) close
5) reload

Result: all staves after the first show an extra clef after the header

extra-clefs.png

Workaround - you can delete them and re-save and they stay deleted.

(BTW, I'd have called this "normal" instead of "major" if that were available, but it's more than "minor")

Comments

• Dec 2, 2018 - 13:55

This seems to apply only when positions reset is accepted, isn't it? Or did you notice the same issue without positions reset?

Reply

• Dec 2, 2018 - 15:34

Weird, I still can't. Not with a build I made last night anyhow. But, your change looks to be good insurance anyhow?

I do wonder, though, we have had issues where people would make some adjustment to a generated element - like the courtesy key signature at the end of a system, making it invisible or changing its horizontal offset - and this would make it non-generated and then bad things would happen. See for example #191426: Added key signature disappears after view change if its courtesy key is invisible. I remember forum discussions too with more detail but can't find them now. Anyhow, the point is, definitely worth testing around this (make some adjustment to a generated element, see if it marks it non-generated, then see if behavior of reset is as expected).

Reply

• Dec 3, 2018 - 15:03

I once suggested that we add a modified flag, so that generated elements can remain generated. I don't think it sparked any discussion, though.

Reply

• Dec 3, 2018 - 15:40

That could probably be good once we have an architecture that allows us to ensure that this flag's value is always properly maintained. Right now introducing this flag would probably be a large pain.

Reply

• Dec 3, 2018 - 16:23

What I am suggesting is to modify an element's modified property instead of its generated property everywhere that currently occurs. The generated property will be set only once, when the element is created. We would only check the modified property in places we currently check the generated property. The current meaning of generated() would become generated() && !modified(), but this will also allow us to check whether or not an element that has been modified was originally generated, which is something that currently cannot be done.

Reply