It should be possible to load a style that is effective to all parts of a score, also a default style for parts (an input field for the last is already provided in the preferences window). This issue is quite important for practical use.
Is someone working on that? If not, I would do it.
Comments
I would love to see this too. I imagine the code to set the default style for parts in preferences is there but just doesn't work, but I think it important to have this be a score setting, so different scores can have different part styles. It seems to me the sort of thing that should probably go in the general style for the score, but I could also see it being in the parts dialog.
But meanwhile, see:
#23956: Setting a default style affects loaded scores, not just new ones
#23957: Crash on chord symbol entry after load of style
#23950: Crash after closing score if loading style that defines chord id
Getting the basic style loading mechanism workking more reliably is probably a prerequisite to what you are wanting here, and maybe looking at these could be a place to start.
Since it appears there is already intent to support this at least as a preference, I'm reclassifying this as a bug. Adding per-score support is more of a feature request, but one that I note has been on the Roadmap for a while now.
https://github.com/musescore/MuseScore/pull/627
I integrated parts of the pull request from Isensee. To keep it as simple as possible i ommited two things:
- no action "save style as default for parts"; along this i also removed the action "save style as default" (in the style menu). It is duplicate functionality, the preference dialog should be used for setting this.
- no "load style" button in the parts dialog. It complicates the dialog and my feeling is that it is also not really required.
Every part has its own style which is handled the same as the style of the main score.
Its easy to set the style of a part with Style->loadStyle.
The implementation of independend styles for every part is debatable. It would be possible to use a common style for all parts of a score. A style change for a part would then change all parts what i believe is what you normally want.
So this is is fixed with that?
If choosing a part style in the parts dialog is not possible, then it is absolutely necessary to change all parts styles when changing one - otherwise the situation is the same as before: you have to click for the parts styles fifteen times or more, or change the defaults even for a singular use.
One disadventage of this handling: The unexperienced user will not find out by himself - he will search for some time, then give up and grumbling start to change the style for each part - and then understand. But since I know about, I personally could live with this.
I agree that ideally, it should be possible to update the style for all parts at once. But there are actually a number of things to consider:
- I feel strongly that the default "Style for parts" should not be a general preference but rather a per score setting. I would use different "Style for parts" settings for different types of scores.
- Being able to share style settings between parts is nice, but being able to have different style settings from part to part is important too. So I prefer having style settings embedded in each part rather than referenced. I'd just want a way to simultaneously update them all. One way I could see this working would be to go to the score and use something like "Style / Parts / General" (or, "Parts / Style / General", or a "Style" button in the File / Parts dialog) to bring up a version of the style dialog that affects parts rather than the score. If the parts are already generated, changes made here would automatically propagate to all parts. Otherwise, this would just set the defaults to be used when the parts are eventually generated. Another would be to have a "Load Style" button in the File / Parts dialog as originally proposed - but it should work as described here (set defaults, sure, but *also* affect already generated parts).
- The most important settings that would normally differ between score and parts are not actually style settings at all, but *page layout* settings: page size, orientation, and margins, plus the spatium value. So, I would also want "Layout / Parts / Page Settings" or the equivalent that I could invoke from the score.
- In addition to needing separate styles from part to part sometimes, eventually I think there would also be separate styles for individual staves *within the score*. For instance, recently we were discussing wanting dynamics to appear above rather than below the staff just for vocal staves.
Looking from the GUI page settings are separated from style but they are really part of the style and are saved in a style file.
Also note that styles are never referenced but always copied. The style is represented in a score file as a simple collection of properties. Its a no-go to reference an outside object in a score file as this would create a lot of problems when moving/sharing the score. This makes the implementation of a default style for parts on a per score basis difficult.
Ok, glad to hear the parts style facility honors page settings. I hadn't tried it, but I just did, and it works great - except that apparently the "Style for parts" preference is not saved/restored when MuseScore is closed and restarted. I'd file that as a bug, but I still want to talk about making this per score instead of a preference, because I think this is very important. I would want different part styles for classical versus jazz score, for educational versus professional, for scores/parts prepapred for one publisher versus another, etc.
I don't think it's neceesary to have "referenced" styles in order to implement Style for parts on a per score basis. In fact, I was thinking about copy, not reference, when I wrote the above. I'll be more specific:
I propose we replace "Edit / Preferences / Score / Style for parts" with a new facility that is per score. We would keep the existing per-part styles exactly as they are, but just as modifications to the score get propagated to the parts, so would changes to style. Ideally, this wouldn't involve style files at all - the regular style dialogs would be reused. I'll describe that method here, because I prefer it and don't think it would be any harder to implement than a similar scheme involving style files.
For now, I'll suggest adding this facility to the existing Style menu. I would add a new submenu Parts, and under that would be Page Settings, General, Text, and perhaps Staff Types (for completeness; not sure it would really be useful). I suppose Load and Save too. These dialogs would look exactly the same as the existing dialogs by those names, except instead of affecting the score, they affect the parts. So there would be a new _partStyle member of the Score object, existing alongside the main _style member. The _partStyle settings would be stored in the score file in the top level score section, in a new tag or some such. _partStyle would start out identical to the score style by default, and could be written as a subset, so the tag would be empty unless you change something.
The semantics would be:
- Any time a change is made to the main score _style, the code would check to see if the changed parameters had previously been customized in _partStyle (eg, if the value of that parameter in _partStyle differs from the "old" value of that parameter in _style). If not, the change should be propagated to _partStyle.
- Any time a change is made to PartStyle (including a change made indirectly via a change to the main score _style), the code should check each individual part's style to see if that parameter had previously been customized. If not, the change should be propagated to the part.
- When a new part is generated via File / Parts, it starts out life inheriting _partStyle as its own _style.
- Subsequent changes to an individual part's style have no effect on anything else. Only change made from within the main score - either to main style or via this new part style facility - would have "global" effects, as described above.
With this implementation, we would not only get per-score default part styles, we would also solve the problem of how to make a style change affect all of the already-generated parts at once.
There are of course simpler-to-implement options that aren't as simple to use but get the job done. And I think the basic approach taken in the original PR above is sound: an explicit command a user would issue at some point to force the loading of a style file into all parts at once. I could see thst command being a button in the File / Parts dialog or a new menu item Style / Load Style for Parts.
I think, we should not complicate things too much. The purpose of styles is: often use and seldom change the preferred layout(s). So it is not necessary to make too much efforts to make frequent changes a little bit easier. Things would not be clearer.
Preferences are peferences. Everyone understands the meaning of that and would not understand the difference of "general" preferences and preferences "per score".
The implementation as given in my pull request satisfies most needs in an easy and natural way.
1. Preferences: Users who prefer one Style for most scores make use of them. It is there "corporate identity".
2. Users who often use different styles will have two style files for each style, one for the Score and one for the parts, and want to load them "per score". They understand, that this are two similar logical steps, and so there are two buttons to press - for the score in the format menu, for the parts I put it into the parts window. You may put it anywhere else, maybe also into the format menu (but I think, the natural place is in the parts window, because then you have not to care for the case that someone trys to load part styles before creating parts). Pressing this button, one style will be loaded for all parts, as mostly needed. That is more natural and intuitive than loading one style for one part and then hope, that the other parts also are affected.
3. The possibility to use different styles for different parts is not an extra implemented feature and may be not quite necessary, but follows automatically from the ingenious designed concept of scores and parts. So let it be for some users with special ambitions and save the efforts to change that.
After all: Marc's idea to propagate style changes of the score to the parts, so far as the values do not differ, is quite charming, should be easy to realize and is quite natural, since other changes in the score also are propagated. If you want, I would like to implement that these days.
I for one would welcome having you work on this. However, I disagree with your assertion:
If this were the case, we wouldn't bother making the distinction for the dozens of other settings. Some settings make sense to be per score and hence are put in the Style menu; others make sense to have be global and hence are put in Edit / Preferences. Generally, anything that affects the actual appearance of the score goes into Style; anything that controls the behavior of the program goes in Preferences. Default style settings affects the appearance of scores of course, but only scores not yet created. So it's impossible to make this a Style setting. However, it *is* possible, and desirable, to have the *part* style setting be per score, as this comes into play aftert he score is created. Users shouldn't have to change Preference settings before generating parts - the score should contain the necessary info.
Consider the basic use case: users creates a score, wants to generate parts using something other than default settings. Say, small half sheet parts for marching band. I thinkt his should be as easy as going to some dialog within the score, setting appropriate page size & scaling parameters, then generating the parts. Whereas int he current system, you would have to first generate a part, then go to that part and customize the page settings, then save style, then go to edit / preferences and set that style file to be used for future parts, then go back to the score and generate the rest of the parts, then hopefully remember to go back to edit / preferences so your next scores doesn't get miniature marching-band-sized parts. This is why users will care if the setting is per score or not: it's the difference between a simple and easy-to-discover mechanism versus a much more complicated and non-obvious sequence.
Now, it is true that the specific mechanism I proposed is a bit involved implementation-wise - although since it borrows existing dialogs and data structures, I actually think it would be not that bad. Still, I'd like to propose another alternative to consider.
In the absence of having chosen a custom Style for parts, the parts inherit style settings from the score, correct? I would claim this is what you want for 99% of style settings. And it is quite easy to predict which settings you might want different: everything in the Page Settings dialog, plus maybe Title text style, System Distance, and the Headers & Footers, and that's probably it for most scores. I'd be willing to forego all of the latter settings, but how about at least having a separate Page Settings for Parts dialog accessible from the main score? I'd even suggest it need only operate on parts not yet created - all it would do is set defaults to be used in File / Parts in preference to the score's own settings. This new dialog could be accessed from the Layout menu or the File / Parts dialog - either would work for me.
I understand your intention. But the subject of this issue was to make style files applyable to parts and to store a style file name for parts within the preferences. That is ok so far.
What we discuss now is how to make it easier to apply style settings to all parts of a score without using a style file. I agree with you, that this would be very helpful for users who have not yet designed there preferred style files or are working on a new design.
Unfortunately is the present menu structure concerning layout functionality, probably on historical reasons, not quite systematically - the layout of musical symbols, text and page format as well as the spatium, that concerns all layout elements are distributed over different menu items. A third branch of layout settings, that contains a more or less arbitrary election of items of both, page settings from "Layout" and other settings from "Style", especially for parts would make things more complicated. Wherever you place it, new MuseScore users will not easy understand.
I would try it this way: Just take the three dialogs "Page settings", "Edit general style", and "Edit text style", rename the button "Apply" into "Apply to score", add two buttons "Apply to parts" and "Apply to actual part". That's all. It's quite systematically, easy to find, easy to implement, with no restrictions even for unexpected preferences of users. I would implicitely apply changes of the score also to the parts, if values where not yet changed, as Marc proposed.
I could also implement that, if there is broader agreement.
It's possible my expectations are set in part by familiarity with other programs that have a use model similar to what I've described, and that a user completely new to notation software might have different expectations.
That said, while my initial reaction is that your idea seems brilliant, I do see issues. In particular, what if one wants to go back and forth between settings score options and part options? Which way would the dialog be populated when you first bring it up? It seems we need not just a way to apply the current settings, but to populate the dialog appropriate in the first place. So that if you wish to modify the part style, the dialog starts off populated with your parts style settings, but if you then wish to modify score style, the dialog starts off that way. So I don't think it's as simple as an apply button. This is why I had the thought of separate menu items - they might bring up the same dialog, but populated as appropriate for the menu item. I don't really think that would confuse people, but I'm open to alternatives.
One alternate idea: the style and page layout dialogs could have tabs at the top, in addition to the "tabs" along the left side. Note sure if tabs within tabs is kosher from a GUI design standpoint, but I wouldn't have a problem with it personally.
When you invoke the dialog from the main score, there would be two tabs: Score and (All) Parts. The dialog would start off on the Score tab. I think GUI guidelines say that hitting OK or Apply should apply settings in all tabs regardless of which tab you are in, but that's fine - assuming you didn't change any settings in the Parts tab, there would be nothing to apply.
If you switch to the Parts tab, you'd see the same controls but now they'd be loaded with the values appropriate for the parts. Any changes here would be applied to all parts - ideally in the manner I described previously (only parameters not already customized in a given party would be updated in that part).
Now, if you invoke the dialog from any a part, you'd have potentially three tabs - Part, All Parts, and Score. I'd argue the last of these really doesn't need to be there - it doesn't make as much sense to edit score properties from a part as it does to edit part properties from a score. But it does make sense to have an "All Parts" option from the part, so you can test the effect of changes easily. Setting "All Parts" options from the score is more of a guessing game. It just needs to be there so you can set reasonable defaults before generation of parts.
You are right, my simple idea was not really good. At the moment I would prefer the last proposal: tabs for parts in the style dialog. The main menu would keep its clarity and the user gets easy access to rich functionality. On the other hand - much detailed work to implement. But the style issue is one of the main criteria of professional usability.
Many details need attention.
1. I think, the same tab construct must be implemented for the page settings.
2. I see no real advantage in setting style properties for parts before generating parts. To enable that, the score class must get a second style member object for parts, and this parts style member object of the score must anyway be kept synchroneous to the parts styles. Alternatively the parts style tab would be omitted or could appear deactivated before parts where generated.
3. If there are individual, different style settings in some parts (even if seldom used, it would be an unnessesary restriction for the users) and a change "for all parts" is applied, it will be difficult to decide the precedences in general after any rule, the users do not know. I would solve that this way: If there are differences, for each differing part comes a pop-up that lets the user decide wether to keep or overwrite the differing parts style. Most users, using uniform part styles, will not even notify this little complication, but those who like most differentiation are completely free and satisfied.
I think I could also realize this concept.
Yes, page layout would need the same facility. If a tab is too much work, then a simple button within the main dialog that says "Parts..." and brings up a second instance of the dialog would do the job just as well. But it's uglier in that you end up having two dialogs open at once.
However, I disagree that making style settings before generating parts isn't important. It just seems wrong to have to first generate parts and then change their settings. If you know the settings beforehand, you should be able to say so. The main reason this actually *matters* is for templates. A template should contain all settings necessary to generate both a new score (immediately upon score creation) and the parts (when the user eventually goes to file / parts). Currently, you can get this effect by generating the parts within the template, so that new documents already have parts created. But I don't think that's ideal from a performance perspective (working with a score that already has parts generated is significantly slower, I believe). And if you add instruments to the template, they won't get the right style.
On the other hand, I'm trying to think through the most important use cases, and I'm coming to believe we can get away with a simpler design that would satisfy most needs pretty well.
First, we need parts to inherit style from the main score by default. This used to happen (1.3) but no longer does. I'd call this a bug. Seems it might be a new one?
Although I would prefer to be able to make *all* part style settings from the score before generating parts, I would settle for page layout settings only. Well, I'll settle for nothing, of course, but I'll stop complaining if I get page layout settings :-). So, either tabs as I initially proposed, a "Parts..." button in the page layout dialog, or tabs, or a new menu item "Layout / Page Settings for Parts" (I think Finale does the latter). This would *only* affect parts not yet generated - there would be no need for it to push changes out to already existing parts.
Yes, this requires a new member in the Score object. I don't see that as a problem. It could either be a full Style object or just a PageFormat object (and of course it would be written and read normally.
I would then say I don't care about making further style changes for parts from the score. Not before generation of parts, not even after. I would be happy to make all further part style changes from the parts (after generating them, obviously). All that is needed is a way to be able to do so for all parts at once. And since you'd already *in* a part, your "Apply To All Parts" button should work fine (no need for tabs). Just visit a representative part, make your customizations, and hit the "Apply To All Parts" button. Add one of these buttons to the Style dialogs as well as the Page Settings dialog, only when in a part.
So - make sure style settings are inherited upon part creation (bug fix), add an "apply to all parts" button to the style & page layout dialogs while in a part, and have a "page settings for parts" facility accessible from the score. That's a pretty low-weight implementation that should meet most needs.
To not be misunderstood - I think, tabs for parts in both, the page format and style dialogs, is the clearest and simplest (from the users point of view) solution.
Even storing a general parts style in the score to copy it to later generated parts of new added instruments, I would not hesitate to implement (I experimented with this already in Version 1.2 to make parts styles available for my own use). But: Before I start working on that I would like to know whether the guardians of MuseScore architecture will accept this extension of the score object.
Once again: I think that a proper and user friendly solution of this issue is very urgent.
(By the way: Working on scores with generated parts will not be slower, because all the staves and their content are not copied, but only held one time in the score object).
I agree, there is no point working on this without some sort of OK from Werner or lasconic.
As for performance, actually, the contents *are* copied. There is a score object in memory (and in the score file) for each part, with a link field within each element to connect the version in the score to the version in the part. Every edit requires the operation to be performed for all linked copies (and there a re a number of outstanding bugs where certain operations are *not* copied).
The performance hit just making the edit on multiple copies wouldn't be so bad in itself. It's the layout() that happens after every edit - thus requiring the entire score to be processed - that is the real issue. As far as I know, this layout() is performed for the part (all parts?) when editing the score. This could be an opportunity for easy improvement if so - wait to layout until the part tab is actually brought into view. I think I may ask about this elsewhere, as this thread is already defocused enough.
See #24631: General style settings not propagated from scores to parts - I filed a bug for the fact that currently, score style setting is not inherited at all when parts are generated.
See also #24732: Style for part not persistent across sessions
Automatically closed -- issue fixed for 2 weeks with no activity.
This was never actually fixed, at least not in the full sense of what was discussed here. What we have is a global way to have one part style as default for all scores, and a reasonable style inheritance mechanism, so parts have a chance of starting out "decent". But if the user wishes to further customize things, he would most likely want to to this *after* parts are generated (so he can see where he is starting from). And he'd probably want to make an adjustment to one part, see that it is good, then apply it to all other parts.
This could be an "Apply To All Parts" button or checkbox in the existing style and page layout dialogs. It could be a new "Load Style For Parts" menu item. It could be an implementation in which parts by default share one style, although it should be possible to override this. It could even be a plugin that copes the current part's style to all other parts if the framework would allow for it. But one way or another, the ability to change style for all parts at once is important. I am finding that fiddling with this is the biggest time sink in preparation of parts for me - which is otherwise becoming a much more efficient process than in 1.3 or than I remember from Finale.
A simple solution, that does not complicate the menu nor the dialog windows structure, would be: If you click "ok" in the style dialogs or the page settings called from working on a part, then will appear a dialog box for choosing whether the changes are applied to the actual or to all parts.
With some more efforts, but more elegant: to put the decision directly into the three dialog windows, but only let appear them, if the dialog was called from working on a part.
If I knew, that one of this proposals has a chance to be accepted, I would implement it.
fixed in c24022f323
Thanks - having this is a nice usability touch!
Automatically closed -- issue fixed for 2 weeks with no activity.
What a great thread. Thanks.