Non-default style settings in score get applied to all parts on reload, leading to bad transposition and other loss of data

• Mar 11, 2019 - 19:05
Reported version
P0 - Critical
Graphical (UI)
S2 - Critical

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: cda4080

1) SATB template (test file at final step: dividers parts.mscz )
2) Add a system divider left/right
3) Create parts (New all -> Ok)
4) Save/Exit/Reload

Result: in parts, Soprano, etc. (press "M" first to disable mm rests), the system dividers appear unexpectedly.


Well, it doesn't seem to be the expected result. A French composer/arranger, whose thread is at the origin of this report, answers (my question was: when you create parts, do you expect system dividers to appear in the parts as well?)
Answer, then:
"No no, no use in the parts, at least (very) rarely. Dividers are useful in scores, especially when hiding empty staves, thus creating pages with 1 or more systems, depending on the density of the score. "

Edit: in this thread:, and especially comments from:

And so, the default should be: no system dividers in the parts. Was it designed this way? And if so, the problem is therefore during the saving process as mentioned.
No dividers in the parts: with a few exceptions, that the user can modify at will by going to one part, and applying to all parts if necessary, the creation of these system dividers.

Can Marc tell us more about this issue?

Title System dividers are displayed in the parts on save/reload Non-default style settings in score get applied to all parts on reload, leading to bad transposition and other loss of data
Severity S3 - Major S2 - Critical
Priority P0 - Critical

First: the dividers should definitely not be in the parts. It's a style setting, and while most style settings get inherited by the parts, this is that should explicitly unset when generating parts, just as we unset concert pitch but set multimeasure resets. We actually do this correctly, which is why the parts look fine at first, but then this info gets lost on save/reload.

Looking into this, I see it's not just system dividers. The same thing happens for any style settings where you change the score to something non-default but leave the parts at the default. And this is very bad. This explains, which alone justifies marking this P0, indeed practically a "blocker". Basically, saving a score with concert pitch turned on will destroy your parts on reload, as the transpositions will be off because the parts get read in as if they too had concert pitch turned on, leading to incorrect transposition.

Beyond that, it's a nuisance that you can't change style settings from the the default in the score without having this automatically apply to the part. But the concert pitch issue and to a lesser extent the divider issue are more than a nuisance.

I suspect this, or at least something similar, may also explain #283996: Text font and size in footer of a part are fixed (to those of score). Changes have no effect. and #285589: MIDI channel assignments lost in parts after save / reopen.

Ideally, the fix to all this is as simple as makng sure when reading style for a part, we take defaults from the general MuseScore defaults (perhaps as customized in Edit / Preferences / Score / Style for part) and not from the parent score. This is different from what we do when generating part, where we do want to inherit from the parent. Alternative might be to force style values to be written in parts if default but parent is not.

In reply to by cadiz1

Regression No Yes

So, after checking (for dividers and concert pitch issue for now), it's a regression which appears on last February 7.

  • This nightly (last one of February 6) works as expected: d9169b3
  • Not this one: a175bfe

There is a few commits between them, but from what I see, this commit might be the better candidate explaining this issue?

To fix: #282918: disabling multimeasure rests in parts doesn't "survive" save/close/reopen

Brilliant, I was going to ask if you could help with that :-)

So, unfortunately, this is a pretty recent regression, looks like it was broken between 3.0.1 and 3.0.2. I guess the previous report of yours about 3.0.2 was actually a duplicate of the one that was marked fixed, but unfortunately that fix broke other things. We're on it, and should get to the bottom of it soon, so thanks for the investigation!

Hmm I found a solution that fixes the stuff about text and font and the transposition stuff, but it doesn't seem to be fixing the midi issues. What I did was just to set the style to MuseScore default styles before reading. It was a really simple fix so far, but I'm investigating further to see if the I can find a reason for the midi issues.

Fixed in branch master, commit 745aee8c6a

_Merge pull request #4792 from peterhieuvu/285781-part-save-reload

fix #285781: loading existing scores no longer applies default style, loading parts no longer inherits style from parent_

Fix version