Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix #316559: part inherits non-default style from score #7383

Merged
merged 1 commit into from
Feb 4, 2021

Conversation

MarcSabatella
Copy link
Contributor

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).

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).
@vpereverzev vpereverzev merged commit cac0628 into musescore:3.x Feb 4, 2021
@igorkorsukov
Copy link
Contributor

@MarcSabatella Could you please port the changes to the master

MarcSabatella added a commit to MarcSabatella/MuseScore that referenced this pull request Feb 17, 2021
@MarcSabatella MarcSabatella mentioned this pull request Feb 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants