Style settings in score migrate to part after save / reload
Reported version
3.6
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
This worked up through 3.6.0, just broke in 3.6.1
1) new score
2) generate parts
3) change any style setting in score - for example, enable concert pitch, or change any text size, etc
4) verify part still has the original setting
5) save
6) close
7) reload
Result: now score and parts share the style.
The score is written just fine - no overrides for the parts show in the MSCX. But upon load, it seems the default are taken from the score when they shouldn't be. And if you then save again, they do get "baked in" to the file.
I'll investigate some, but I assume this is tied in to all the changes in style handling and really should be looked at with a bigger picture view than I have.
Fix version
3.6.2
Comments
See https://github.com/musescore/MuseScore/pull/7293/files#r566490518 for my analysis.
https://github.com/musescore/MuseScore/pull/7383
Fixed in branch 3.x, commit cac0628d4f
_fix #316559: part inherits non-default style from score
Resolves: https://musescore.org/en/node/316559
When reading a score with parts, we currently set the defaults
for all styles in the score to those of the score itself.
This was done to make sure the "keep old style" option worked
for both score and for parts.
But this is not the right answer: scores can and do
often have different style settings from the parts.
Most critically, the score might be concert pitch
while the parts are transposed.
The result right now is that the parts are now somehwat "corrupt":
they claim to be in concert pitch mode and the pitches display that way,
but the key signatures are transposed.
That's the most critical effect of this,
but in general, there are many other situations where the score
can have different style settings from the parts,
and right now this difference is getting lost on save/reload.
Because the default for style in part is set from the score,
this means that if the score has any non-default settings,
these get propagate to the part on read even though the part
was using the actual program default settings.
Fix is to set the default style for the part on read
not to the current style of the score,
but to its own default.
This uses the same code as when reading the score,
checking the default style version,
and resolving the style defaults accordingly.
Thus, the default values for style settings not overriden in the part
come not from the current score settings,
but from the defaaults for the score.
This is consistent with how it worked before 3.6,
when there was just one set of defaults applied always (baseStyle)._
Automatically closed -- issue fixed for 2 weeks with no activity.