Reference style files in scores

• Jan 29, 2014 - 21:55
S5 - Suggestion

I was confused about the functionality of user-saved style files. I thought that when I loaded a style file, it was referenced by the score so that any future changes to the style file would be reflected upon reload.

It appears that the style file is copied into the score file as a one-time operation. Assuming I understand it correctly, my request would be to have the style file referenced by the score so that changes to the style file would be seen in the score. Here are some thoughts on how this might work:

- the existing behavior of copying the style into the store should persist as a fallback if the style file goes missing
- when a style is loaded and applied to a score, it's path should be saved with the score
- when a score is opened and it has a saved style file path, that style should be applied before rendering the score
- if the style file cannot be found, the user should be prompted to find the style file and, if found, the new path should be saved (if not, the path should be cleared?)
- the above behavior should also work for batch operations (e.g., print album)

I don't know how the style files are versioned (if at all) so there may need to be handling for cases where a style file is older and does not specify a particular value, consider:

- new score
- load newer style file that covers all attributes
- load older style that omits an attribute

I would expect to get the equivalent of:

- new score
- apply old style

and not have any of the newer style's attributes left behind.


I have mixed feelings about this. I don't like the idea that changes to some file on the file system might affect scores already completed. I see the rationale to want to be able to update the style for multiple things at once, but I think maybe I'd prefer a more direct way to do that. Like, a plugin that allows to select a set of scores and then applies a given style file to them. And realistically, it seems the main use case for this is to update all parts of a single score simultaneously, and there might be better ways still of achieving that effect (eg, a dedicated "Part Style" dialog access from the score).

My use-case is consistency across multiple files. If I'm on song #15 of 30 and realize things would look nicer with more/less space of a certain type, I'd like not to have to go back and load+apply style for the other 29 files. I was actually doing this last night when I typed my comments...

It is also hard to keep track of which files have been manually updated, and referencing the style file on disk is a an easy way to make sure they are always current when rendered. I'm thinking of this like a CSS stylesheet in the web world - they are incorporated by reference and they do effect things live. Similar to an #include.

Maybe there could be a per-score option for "one shot" versus "live" style application.

Of course, there is the question of what to do when the user edits the style settings on a "live" score. These would likely need to be a set of local style overrides that are applied after the live style until they were applied back to the global style file.

Refering to external resources has lots of problems. We want to make sure that scores can be moved and shared in an easy way. That means that scores should be complete and not rely on external files.