Measure Number Rectangle Frame Style in Parts Affected By Settings in Score
So here are the steps for reference:
1. Create a new score with at least two instruments.
2. Generate parts. It doesn't matter whether generating all parts.
3. Switch to a part, close the Create multimeasure rests option in Style ->Score for this part. This is mainly to show measure number in this part. You can also add some notes in the score to let the measure number to be shown in this part. For now, the measure number should have no frame by default.
4. Switch back to the full score. Go to Format -> Style -> Text Styles -> Measure Number -> Frame. Change the value to Rectangle. You can also select a measure number and change the setting and set it as style in the Inspector. Doesn't matter.
5. Save the file and reopen it.
6. Switch to the part. Now the measure number in the part will be added to a rectangle frame, which should not be there.
Environment: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.6.1.515740707, revision: d0fc8e9
If you try to set the frame to None in the part, it won't work. After you save and reload the file, the rectangle frame is still there. So If you want to have a rectangle framed measure numbers in score, while no framed measure numbers in part, I think there is no workaround currently.
For further reference, the circle frame option works correctly. Setting the rectangle frame in the part won't affect the setting in the score. So it's just a Score (master) - Part (slave) affect with this option, if what I'm saying make sense:)
I also uploaded a GIF record that shows how to reproduce this issue.
And here is the test file I created following the above procedure.
test.mscz
You can change the frame style of the measure number in Violin part to None (make sure changing the style, not the setting of the individual measure number). After save and reload the file, the frame is still there.
Hope that helps. Thank you.
Comments
I can confirm this behavior, and the fact that it is a regression, at least since 3.5.2 (not sure about 3.6.0). Would you mind submitting this as an official bug report to the issue teacker (see Support menu) above, severity "major"? You can just copy&paste the steps you listed here, which are perfectly clear - no need to re-upload the attachments.
Not just measure numbers - same thing happens for other text styles. So, add a staff text to the score, frame a frame, set as style, save, reload - now it's in the part too. It's fine in the file itself when I look with an editor, somehow it gets off during the read. Could have something to do with the change to how style defaults are handled in 3.6 (to allow 3.5 & 3.6 to have different defaults).
In reply to Not just measure numbers -… by Marc Sabatella
Sorry for the late update... Just starting a new day...:)
Yeah. Seems there are some connections between score and parts that caused this effect. Thank you for your work for resolving these detail issues and make Musescore such a professional software.
I'll go ahead and submit the issue as I now realize the scope is rather bigger than just measure number frames.
In reply to I'll go ahead and submit the… by Marc Sabatella
Is it #316559: Style settings in score migrate to part after save / reload?
In reply to Is it #316559: Style… by Jojo-Schmitz
Oh, thanks for the tip! I think it covers this issue:)
In reply to Is it #316559: Style… by Jojo-Schmitz
Yep, that's the issue. I looked at this is confirmed it at first and though, hmm, frames on measure numbers don't work right, how odd, but not that big a deal. I know we made some changes to both frames and to measures numbers and figured some signal just got crossed with this one setting. Then tested some more and realized frames on other text styles were also affected. Then I realized other text style settings, like size etc, were also affected. And then I realized, it's all style settings :-(.
I do understand the cause - it's related to the code designed to allow "keep old style" to work when importing older scores, which had other bugs that were fixed in 3.6.0 but unfortunately that fix broke this. I have a proposed solution, too. But everything having to do this code is a bit foreign to me and as this shows, it's quite possible to fix one thing and break another, so I'm not comfortable submitting the fix myself. Instead, I've just documented my suggestion and pointed the right people at it. But we're looking at a 3.6.2 soon anyhow for a few other reasons, and I have no doubt we'll have this fixed for then.
Until then, my advice is, don't change style settings in the score that you don't duplicated in parts. Maybe make a list of the settings you'd like to change, but see if you can hold off on actually doing it until 3.6.2 comes out. Or, I guess, save two copies of the score for now, one with the settings you like for the score, one with the settings you like for the parts. I realize, far from ideal, but I think it's the best I can suggest for now.
In reply to Yep, that's the issue. I… by Marc Sabatella
Thank you for the advice. I always test in newly released version while do my actual work in older version instead, though maybe I have to deal with some bugs/missing features that are already fixed/added in the new version. But I think overall it's no big deal for me :).
I hope the fixing progress goes well.
In reply to Thank you for the advice. I… by strman
I just submitted a potential fix, but I'll let the people who actually worked on that area of the code take it from there.
It's kind of mostly harmless for many things, but, don't try saving a score in concert pitch with the parts transposed, unless using atonal key signature. Otherwise, the keys get messed up on account of this.