Non-default style settings in score get applied to all parts on reload, leading to bad transposition and other loss of data
P0 - Critical
S2 - Critical
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 220.127.116.1163, 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)
Result: in parts, Soprano, etc. (press "M" first to disable mm rests), the system dividers appear unexpectedly.
Unexpected is that they don't appear before the save/reload
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?)
"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: https://musescore.org/fr/node/285775, and especially comments from: https://musescore.org/fr/node/285775#comment-902557
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?
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 https://musescore.org/en/node/285439, 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.
This other issue (#283497: Setting of disable multimeasure rests in parts is lost after saving) had gone completely unnoticed.
I guess it's probably related too?
But indeed, the concert pitch issue is the worst.
In reply to This other thread (#283497:… by cadiz1
So, after checking (for dividers and concert pitch issue for now), it's a regression which appears on last February 7.
There is a few commits between them, but from what I see, this commit might be the better candidate explaining this issue? https://github.com/musescore/MuseScore/pull/4633/files
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.
Midi issue is not related to mentioned others (concert pitch, dividers)
Here is the PR for the solution I partially mentioned a couple comments up :)
Fixed in branch master, commit 3380821548
fix #285781: fix part saving and loading of scores
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_
Automatically closed -- issue fixed for 2 weeks with no activity.