MSCX format: Don't duplicate elements for each part

• Oct 14, 2020 - 19:53
Reported version
S5 - Suggestion

MSCX files contain a main score with all measures for all instruments, followed by sub-scores for each of the extracted parts. In each part's sub-score, all staves, measures, frames, and elements for instruments in that part are duplicated from the main score. This is very inefficient in terms of space, and overly complicates the diff output when changes are made to a file under version control.

Instead of duplicating everything in the parts, we should write out the measures etc. in the main score only, along with any differences between the score and the parts. The separate sub-scores should only be used to store global differences, such as changes to styles and page layout.

The following things can differ between the score and the parts:

  1. Page Layout and Style
  2. Inspector properties for individual elements (size, position, colour, font, etc.)
  3. Part Name text in Vertical Frames

Comment below if I have missed anything.


Besides the mentioned Part Name text, some other elements may also be present only in the main score or in some specific part. This is the case at least for layout-specific elements: layout breaks, spacers, maybe system header elements like measure numbers, clefs or key signatures which are also written to MSCX file if their properties are customized.

Maybe even nothing needs to get written into any part (except that it exists and for which instrument(s) and/or voice(s)), just on any change in/to the part to any non-linked element, doing a "copy on write".

I really agree with this idea. (I already posted this message in the developer chat, but I will also post it here, for completeness.)

Finale has a quite good system for managing parts, which could inspire us. Initially, everything in a part is "linked", so it appears just as it does in the score. If you edit any item in a part, that item gets "unlinked" from the score. So editing a part only affects that part, but editing the score affects usually both the score and the parts. Finale shows unlinked items by giving them a different color, and the user has the option to "relink" them to the score, which removes the overridden settings and makes the item follow the score again. This way, we would only need to store some basic layout settings and only the unlinked items for the parts, instead of storing a kind of "copy" of the score for each part.
Regarding user-friendliness: I have used Finale for over five years and this system worked quite well for me: usually you don't need to worry about the score and parts getting out of sync, and if you still want to tweak something in a part only, you can still easily do so.