How to group parts?

[cecilios]

I was looking at the new section for Parts to the MNX-Common by Example page and it raised the question of how to group parts (the MusicXML part-group elements). I've been looking in the specification and unless I've missed something, I have not found any reference to this.

I would appreciate some comments on this or what ideas are you considering for representing groups. Thank you.

In my oppinion grouping parts is a very important organizational element and this could affect current high level MNX structure, and should be addressed sooner than details of the specification.

[notator]

Yes. I also think this needs fixing. §4.1 says that a Part can have one or more staves that "relate(s) to a single performer or group of performers". That can't be right. A Part defines a group of staves, connected by a single barline. Voices can move from one of these staves to another. If, for example, the Part was a group of woodwind instruments, should a bassoon voice on a bassoon staff really be allowed to move to a clarinet staff? Note also that in §6.11 (and §6.1.9 Example 10) a Part can have "part-name" and "part-abbreviation" attributes, but there is no provision for naming individual staves. So there's currently no way to represent a group of woodwinds connected by a single barline.

[clnoel]

What about choral pieces that sometimes have the SATB each on a separate staff, and sometimes have the female voices on one staff and the male voices on one staff? You have to be able to move a "voice" from one staff to another to correctly represent the original.

-- Christina

[notator]

Sorry, I'm still trying to understand this myself. Probably I was wrong, and §4.1 is correct:

Each part is a grouping of related musical material that relates to a single performer or set of performers.

and all that's missing is the ability to name particular staves and/or voices. (§6.11 looks a bit unfinished...)

§4.5 says (my emphasis)

[...] A voice is a set of sequences in different measures, but within the same part. The sequences within this set can be thought of as constituting a single musical voice throughout the score. Thus they are an organizational construct, rather than a notational one. A given voice need not be expressed in every single measure of a part. It may be present in some measures, and absent in others.

According to §6.2.2, sequences can have both a cross-measure "voice" attribute (so four sequences of "sequence" elements in the same Part could be labelled as belonging to voices S, A, T and B) and a "staff" attribute denoting the staff index (from top to bottom in the Part). So @clnoel 's example should be no problem. However, as far as I can see, we are not told explicitly how to order the voices on each staff. Presumably, as with staves, voices should ALWAYS occur in the XML in the same order as they are to appear in the score (top to bottom).

Apropos: I had a problem with MNX-Common by Example, Multiple Voices. In that example, the lower voice is presented first, so it should really have its stems pointing upwards. I had to go through a few hoops to make the example look like the given graphic. I think that voices MUST be presented in top to bottom order, otherwise things get unnecessarily complicated, -- and that the example does not actually match the graphic.

Summary of my current understanding (is this right?):

1. Sequences belong to the same voice if they have the same voice identifier.
2. A particular voice does not have to have a sequence in every measure in the score, but a particular voice identifier means the same voice whenever it occurs in the score.
3. Voice identifiers in "sequence" elements (hence voices) are simply a technique for defining layout. They have no necessary relation to the voice's content (Klangfarbe etc.)
4. We need to be able to give a printed name to each voice and/or staff. How else could it be made clear where the voices move when they move from two staves (S+A, T+B) to four staves (S,A,T,B) and back?

Is the distinction between (non-printed) voice identifier and (printed) voice name the distinction needed to solve Issue #183? Is the (internal MNX-Common) voice identifier "layout", and the voice name (printed in the score) "analytical"?

[clnoel]

However, as far as I can see, we are not told explicitly how to order the voices on each staff. Presumably, as with staves, voices should ALWAYS occur in the XML in the same order as they are to appear in the score (top to bottom).

If we alter this to not knowing how to order the staves in the system, then I agree here. Voices should appear on staves wherever their associated notes should appear. But the ordering of the staves is a layout issue that needs to continue to be addressed.

Whenever the system layout changes we will need labels. This occurs at the beginning of the piece, anywhere the arrangement of voices on staves changes, anywhere the number of visible staves changes, and probably some other places that an editor chooses to put one in for clarity.

[notator]

@clnoel I'm not sure I understand you there. According to §4.1:

Staves in CWMN are identified within a part by a unique staff index. The topmost staff in a part has a staff index of 1; staves below the topmost staff are identified with successively increasing indices.

I think things should be kept as simple as possible: voices in staves, staves in parts, parts in systems and systems in the score should all be consistently organised: The order in which the elements occur in the XML should be the top to bottom order in the score. Any of these orderings (except systems in the score) can change at any point in the score/XML. But for that to work we need staff/voice names (in the score)...

[clnoel]

Oh... arg... I skipped the "part" in the hierarchy. I meant staves ordered within the part not within the system. Parts would be ordered within the system. My point, though, is that voices don't order in the staff. Once a voice is in a staff, it can't really have a vertical order relative to other voices, because the note sequences might cross each other musically.

[notator]

I don't see any problem with voices crossing musically on a staff. An upper voice (the one with stems up) can have pitches below those of the lower voice (that has stems down). I'd like to suggest that the top-bottom order of voices in a part should remain the same during the whole score, regardless of which staff (inside the part) they are written on. To extend your example of (S+A, T+B) changing to (S, A, T, B): If S and T were tacet for a few measures, A and B could be notated on a single staff, but their top-bottom order still would not change (i.e. A would be notated above B on the staff). I think its common practice for the notated top-bottom order of instruments per system not to change during a score, even if instruments sometimes get left out or are moved to different staves.

[notator]

This issue is collecting TODO items for the voice to system hierarchy, and may end up as a Pull Request, so here's a summary of the items so far (comments and corrections welcome, of course):

• It must be possible to give each voice in a score a printed name (§6.2.2, §6.11). This is in addition to the "voice identifier" used to clarify voice leading when the voice is anonymous (e.g. when a voice changes staves on a piano's grand staff).
• The top to bottom order of voices (in each system of a score) should never change, either in the XML or in the printed score. (Note that not all voices have to be present all the time, so the "top to bottom order" can always have gaps). This means that:
  • the top to bottom order of Parts (in XML and score) should be fixed (in §6.1.7)
  • voices should always be presented in top to bottom order inside each Part, regardless of the staff (inside the Part) to which they are assigned (§6.11).
  • sequence elements must be presented in top to bottom order inside Measures (§6.2.1). (Voices are defined as sequences of Sequence elements across different Measures. Voice identifiers are used for disambiguation when the number of voices changes.)

I'd like to discuss whether there should be a maximum number of voices per staff. (Collision checking gets exponentially more difficult as the number of voices per staff increases, so it might encourage more software developers to read/write standard MNX-Common if the requirement to support unlimited numbers of voices per staff were removed. Unlimited voices per staff could be allowed in some other profile.) My own feeling is that standard MNX-Common should have a maximum of two voices per staff. Each voice is rhythmically independent of the others so, in the above SATB example, the two voices could then only be named "S+A" and "T+B" if each just consisted of simple two-part chords.

[bhamblok]

@notator I disagree on limiting the number of voices per staff. There are tons of examples in literature where there are more than 2 voices on a staff (to name most of Bach's preludes & fugues as an example). In choral music, there are also lot's of examples where all voices are again split up in multiple voices like "SSAATTBB", and still visualised on 2 staves.

[notator]

@bhamblok you're right, of course, about the Bach examples, but I'm still not sure that this belongs in the standard profile. As I said, I think this needs discussing. Can you give an example of SSAATTBB visualized on 2 staves with more than 2 (rhythmically independent) voices per staff?

[adrianholovaty]

@notator This GitHub issue has gotten quite a ways off-topic...! Regarding multiple voices, I don't see a good reason to limit the number of voices in an MNX-Common file.

To the original issue topic (how to group parts), this still needs to be designed. My gut take on this is that we'd have a separate section, somewhere in the document, which would let us specify the groups by listing IDs. (For example, "this group consists of parts P1 and P2, and it uses a bracket.")

[cecilios]

@adrianholovaty Thanks for your thoughts. They are in line with current MusicXML approach. Days after opening this issue I found #33 that seem to address the same concerns but, probably, with a very different implementation. I still think that this issue should receive more priority because depending on the final decision it could affect significantly to current MNX skeleton.

[notator]

@adrianholovaty Okay, granted: the question of how many voices per staff there should be in the standard profile is off-topic. The idea really belongs in the debate about profiles (#68, #175), so I'll save it for when we get back to those issues.

But the rest of the above thread, containing a review of the container hierarchy, is very much on-topic. (@cecilios asked for more discussion around the subject of grouping parts, because the result might affect the basic structure of MNX-Common documents. The container hierarchy is the basic structure of an MNX document.) The current state of this discussion is that

• Parts should not be grouped by putting them in another container, and
• Parts should be ordered (in the XML) in their top to bottom order in the score. (I have yet to hear a convincing argument as to why the Parts should be an unordered collection.)

This affects the way brackets can be defined. You said:

My gut take on this is that we'd have a separate section, somewhere in the document, which would let us specify the groups by listing IDs. (For example, "this group consists of parts P1 and P2, and it uses a bracket.")

Here are some thoughts to follow that up:

• The information could go in global measure directions element(s) (where we know how many Parts currently exist).
• It must be possible to define "nested" brackets and their type (e.g. a curly piano bracket for a single piano Part, left of a square bracket that encompasses the piano part and other Parts. Or a square bracket, grouping two trumpet staves, left of a larger square bracket encompassing the whole brass section.) Maybe that can be done by implication: Brackets that overlap are simply printed with the small one to the left of the longer one.
• Do we need more than two bracket types ("curly", "square") ?
• If Parts are always in a fixed top to bottom order, then bracket definitions only need to include the top and bottom part IDs. If the Parts are in random order, then you need to define the bracket using an unordered set of part IDs (which would be error prone, and make the tracking of bracket heights more difficult when Parts disappear and reappear).
• This means that Parts MUST have an ID. It could either be a mandatory ID attribute in the Part definition (§6.1.9, §6.11), or there could be an automatic allocation of part IDs (maybe the string "part" followed by an integer that indicates the top to bottom position of the parts in the score). N.B.: The Part ID is not the same as the part's name, because there could be more than one part with the same name (e.g. "Violin").

BTW: I think #33 could now be closed.

[notator]

Sorry but, looking closely at the problem of extracting Parts, I've come to the conclusion that the above review of the container hierarchy must be wrong.

I now think that the Spec is only talking about anonymous voices that can be played by one performer (so the voices don't need names). A Part should be an entity that can be extracted from a score to be played by one performer. As I pointed out above, §4.1 is wrong after all, when it says:

Each part is a grouping of related musical material that relates to a single performer or set of performers.

The spec needs to distinguish between different staff types that occur at different levels in the container hierarchy:

• A Part (for a single performer) can contain more than one part-staff. A part-staff can contain more than one (anonymous) voice. For example, a piano grand staff consists of two part-staves.
• A system-staff can contain more than one (named) Part (e.g. 8 Horns). Each system-staff can contain more than one voice, each of which can be associated with (contain?) more than one (named) Part.

If this is correct, a "part-group" can be a set of system-staves connected by a single barline.

So far, so good, but a problem arises, because MNX-Common is designed for flexible layout. Given an orchestra score containing eight horns (horn Parts) for example: There is no information in the XML as to where the system breaks happen, so there can be no information as to how many system-staves to use for the eight horns on each system. Also, there can be no information in MNX-Common as to how to name the system-staves in the score to say which Parts they apply to. These things can neither be imported into, nor exported from, instantiating applications. They can only exist in the instatiations themselves. The instantiating applications (or their users) have to provide this information themselves.

Nevertheless, it should still be possible to declare the fixed, top to bottom order of the (single performer) Parts in the global measure directions, and to define (nested) brackets (independently of the group-barlines) that enclose them...

Still working on this.

[clnoel]

Okay, if we're still looking at making definitions, I want to talk about the following visual groupings we see in a piece of music.

1) Staff - a set of horizontal lines, where musical notation can be arranged for display 2) Grand Staff - two staves vertically linked by a curly brace, and sharing measure barlines, used to facilitate a part that has enough range to be confusing when put on a single staff. (e.g. piano or organ) 3) Grouped Staves - a set of staves or grand staves connected by a curly or square brace, and not sharing measure barlines, used to indicate that the parts involved are closely linked. (e.g. SATB voices or 8 Horns). 4) System - a set of staves, grand staves, and/or grouped staves connected by a vertical system barline, representing every part in the current layout.

I believe that what I am calling "Grouped Staves" above is the source of the original question (Part-Groups), especially in regards to how this might affect the MNX-Common hierarchy.

If that understanding is correct, then in my opinion, "Grouped Staves" are entirely a layout question, as is the ordering of the staves in the system, and as such are completely separate from the musical/notational definition of the notes in the parts, just as the number of measures per system are separate (because they depend on page size). And we should not be worrying about it right now, because we are trying to separate out such layout concerns into their own section rather than mixing them in. This way, the same MNX document can be easily used to either faithfully reproduce the original by using that layout information, or to easily order/reorder or selectively include whichever parts are wanted by disregarding it.

Which doesn't mean that the parts don't need a name to be used for display. Probably they need both a full name and an "abbreviated" name, such as "Soprano" and "S". The layout specification can then choose when/how to display these names.

If we are ready to start talking about how to map parts onto staves to create layouts, then I'm more than willing to help dig into it, but I think we're not there yet, considering that we are still defining how repeats and second endings work when we only have one part.

--Christina

[cecilios]

Thanks @clnoel , a very clear explanation.

I believe that what I am calling "Grouped Staves" above is the source of the original question (Part-Groups),

Yes, that were my concerns.

in my opinion, "Grouped Staves" are entirely a layout question

I see three approaches to this:

• The semantic approach suggested by @joeberkovitz at #33
• Your approach, a layout question to be solved later
• The MusicXML approach as suggested by @adrianholovaty at https://github.com/w3c/mnx/issues/185#issuecomment-635364063

I'm not voting or suggesting any approach. My concerns are that it is necessary to define which approach will be choosen so that we all are aware of possible implications, instead of proceeding with details and later, when finally this be studied, having to go back or having to implement 'hacks' to avoid having to go back.

[clnoel]

Actually, I just realized that #57 (page and system flow) is in active review right now, so we do need to be worrying about this now!

My point about this being a layout issues is that in a complex orchestral piece, you might have the 8 horns part-group as a grouped stave on the conductor's score, be printed out as the entire layout for the horns themselves, or ignored entirely in order to produce a score that is just one of the 8 horns. And all of those are valid options for which it would be nice to not have to have separate MNX files for. Instead, we specify each of the 8 horn parts separately, and define score-layout elements for the composer, for the horn group, and for each horn separately.

Each of these different score-layouts would treat the group in different ways. So, if we have something like:

<score-layout name="Full Score">
    <system-layout name="Grouped Parts">
        <part-layout part="Violin 1"/>
        <group-parts type="bracket">
            <part-layout part="Horn 1"/>
            ...
            <part-layout part="Horn 8"/>
        </group-parts>
        ...
        <part-layout part="Piano" type="Grand"/>
    </system-layout>
    <page-layout page-number="1">
        <system system-layout-id="Grouped Parts" start-measure-id=1 end-measure-id=4 show-name="Full"/>
    </page-layout>
    <page-layout page-number="2">
        <system system-layout-id="Grouped Parts" start-measure-id=5 end-measure-id=10 show-name="Abbreviated"/>
    </page-layout>
    ...
</score-layout>
<score-layout name="Horn Section">
    <system-layout name="Horn Solo">
        <part-layout part="Horn 1"/>
    </system-layout>
    <system-layout name="All Horns">
        <part-layout part="Horn 1"/>
        ...
        <part-layout part="Horn 8"/>
    </system-layout>
    <page-layout page-number="1">
        <system system-layout-id="Horn Solo" start-measure-id=1 end-measure-id=4 show-name="Full"/>
        <system system-layout-id="Horn Solo" start-measure-id=5 end-measure-id=8 />
        <system system-layout-id="All Horns" start-measure-id=9 end-measure-id=12 show-name="Full"/>
    </page-layout>  
    ...
</score-layout>
<score-layout name="Horn 1">
    <system-layout name="Horn 1">
        <part-layout part="Horn 1" combine-full-measure-rests=true/>
    </system-layout>
    <page-layout page-number="1" show-name="Full">
        <system system-layout-id="Horn 1" start-measure-id=1 end-measure-id=4/>
        <system system-layout-id="Horn 1" start-measure-id=5 end-measure-id=8/>
        <system system-layout-id="Horn 1" start-measure-id=9 end-measure-id=12/>
        ...
    </page-layout>
    ...
</score-layout>
<score-layout name="Horn 2">
    <system-layout name="Horn 2">
        <part-layout part="Horn 2" combine-full-measure-rests=true/>
    </system-layout>
    <page-layout page-number="1" show-name="Full">
        <system system-layout-id="Horn 2" start-measure-id=1 end-measure-id=12/>        
        ...
    </page-layout>
    ...
</score-layout>

There are a lot of things in this proposal that are out of scope for this discussion (and in fact, I should probably post it over at #57 ) but one thing it definitely does is show how we can group parts. Also, I'm not attached to the naming conventions for any of this, just the general idea.

[cecilios]

@clnoel Nice approach! I like it

[clnoel]

@notator I'd especially like your input. I've posted an expanded version at https://github.com/w3c/mnx/issues/57#issuecomment-636993268 .

[notator]

@clnoel Many, many thanks for

• pointing out that #57 exists and is in active review.
• posting some real code that we can discuss! :-)

I've got a lot to say about the code, but its rather off topic here so I'll continue that discussion in #57, as you suggest.

I think we can finish with this issue (#185) when we're really sure what we mean by a "Part" and a "group of Parts".

Further to my last posting, I now think that a "Part" should be defined in terms of booklets rather than performers: A "Part" is the smallest sub-unit of an MNX-Common file that can be printed in a separate booklet. (All the Parts defined in the file having the same number of measures as the Full Score.) Booklets containing just one, or an arbitrary combination of Parts can be defined and printed. Here are some examples, to illustrate what I mean:

• When one hires the score and parts for a classical symphony, one gets maybe six copies of the Viola Part. There's only one Viola Part defined in the MNX-Common file, but it can be printed several times, and played by more than one player. Even if there is only one Part defined for the Violas, some of its systems may contain more than one concurrent (part-)staff (divisi Violas).
• Not all the Parts defined in an MNX-Common file need to be printed in the Full Score. It would be perfectly possible to include a Part containing a piano reduction of the Full Score in the file. Such a Part would not be included in the Full Score itself but, for example, could be included with the choir Part(s) to create a score that can be used in rehearsals.
• Cues: It should be possible to define cues (Parts written on small staves) that can be included in booklets containing instrumental Parts. The same cue could very well be useful in different instrumental Part-booklets.

@cecilios, @clnoel: I think we are very close to agreement on the answer to this issue's question: "How to group Parts?". The simple answer is to draw a continuous barline through all the (system-)staves that contain the Parts, and define appropriate brackets to the left of the system. But this still needs refining a bit: I'm not sure what you think, but I suspect that part-staves should not be joined by the same barline. Groups of Parts containing Parts that have part-staves should only be indicated using the brackets on the left of the system. Barlines that join part-staves are important for pointing out single players to a conductor, so should not be overwritten. For example: If a piano Part (on a grand staff) is part of a percussion group, should there be a single barline that goes through all the percussion Parts and the piano's grand staff? My inclination is to say no, and that the group should only be indicated by the bracket(s) to the left of the system. What do you think?

Now for #57! :-)

[cecilios]

@notator:

For example: If a piano Part (on a grand staff) is part of a percussion group, should there be a single barline that goes through all the percussion Parts and the piano's grand staff?

In my opinion this should be like in MusicXML: an option in the group definition.

[notator]

@cecilios Yes. Agreed. Good idea!

[clnoel]

@notator Agreed on the "booklet" idea. That would also resolve the way I was struggling to define the soprano "part" of an SATB piece when there is a point at which the SA line has three notes. Especially if there is only one such place throughout the piece (like the final note). It didn't feel right to have to define a second-soprano part for the whole piece because of that one divisi, but we had restricted part to one performer. I like the idea of thinking in "booklets" although I'm not sure I'm attached to the name itself.

(off-topic: I have a choral background, not a composer/symphonic one, so I tend to think in terms of those pieces of music!)

@cecilios Yes. Attaching a barline attribute to the group-parts tag should do that. single-part or cross-part should be sufficient options.

[cecilios]

@cnoel

single-part or cross-part should be sufficient options.

And what about Mensurstrich barlines? Probably the set of options should be that of MusicXML.

[clnoel]

@cecilios 🤦 Oops. Despite having been very involved in a Mensurstrich conversation not that long ago, it completely slipped my mind. You're right. The MusicXML group-barline enumeration covers all three options. Does anyone ever connect parts with dashed/dotted barlines even when the part's barlines are solid?

@notator What about percussion parts? In a full score they are frequently done on an instrument-by-instrument basis, but there are usually far fewer performers than the number of potential instruments. I can't imagine anyone ever putting out a "booklet" for a triangle part even though it is a stave in the conductor score. Although I guess you could.

[notator]

Thanks @clnoel for the link to the group-barline enumeration. Those options should, of course, also be supported by MNX-Common. They don't, of course, answer the question as to whether the system-staff barlines should override the part-staff barlines. That's an option which, as @cecilios said in https://github.com/w3c/mnx/issues/185#issuecomment-637428742, should go in the group definition. I've made a note to do that in my next posting to #57. Has anyone got a link to a corresponding option in MusicXML?

I can't imagine anyone ever putting out a "booklet" for a triangle part even though it is a stave in the conductor score.

Particular Parts don't have to appear in every system (that's something I'm looking at for #57)... :-)

Its up to the author of the file to decide how to organise percussion parts. Printed booklets can be defined to contain any combination of Parts, and the number of staves in each Part can vary from system to system (possibly from measure to measure). Presumably, its possible to define the number of stafflines in a staff (I haven't checked). Percussion booklets should especially benefit from the flexibility of this scheme: The same physical triangle(s) can be defined to be a Part that exists in different booklets at different times. You could make a booklet for just the triangle(s) if they were intended for a particular player, or if they were placed a long way from the other instruments and the players needed to walk a long way to get to them without carrying booklets about...

[clnoel]

@notator I was responding to what you said:

A "Part" is the smallest sub-unit of an MNX-Common file that can be printed in a separate booklet.

Although I just think I was being nit-picky. Because, as you point out, you could print just the triangle part if you really wanted to.

I agree about the flexibility of having these score-layouts for percussion. The conductor can get his one-line staves with the percussion parts on it, and the percussionists themselves can get whatever other notation they want, like having the triangle part appear on a staff with another part, except with a triangle-shaped notehead.

(Off-topic: I've seen some weird percussion pieces come through Musicnotes recently. There's no standard at all that I can see.)

[notator]

@clnoel Its very good, even important, to be nit-picky here. All, even rather vague, reservations need to be raised and investigated so that we can be sure we're talking the same language, and that there's nothing we've overlooked. Having to think a bit more about percussion parts was, I think, very useful.

@adrianholovaty I don't think we can move on to #57 before the results of this issue (#185) have been incorporated into the Draft Spec. It turns out that @cecilios concerns were completely justified. Its currently impossible to group Parts (as in group barline) because the Spec has no "system" container that can contain concurrent "system-staves". We can't discuss how to define systems or system breaks if such things don't exist in the Spec. (A "system-staff" is a staff element (contained by a "system") that contains voices that are, or contain, lists of one or more PartIDs).

The Spec also needs to provide clear definitions of what it currently calls "staff" and "part".

Staff: My suggestion would be to rename the current "staff" as "part-staff". A "part-staff" is a staff element (contained by a Part) that contains anonymous voices.

Part: §4.1 says

A score consists of multiple parts. Each part is a grouping of related musical material that relates to a single performer or set of performers. It has the same temporal extent as the score overall, but presents a slice of content that is relevant to a single instrument or a group of related instruments.

As you can see from the above discussion, defining a Part in terms of performers or sets of performers (or even instruments or groups of related instruments) leads to endless misunderstandings, and is much less powerful than defining it in terms of printability. §6.1.9 says

The part element represents a set of measures which describe a single part within the score.

which doesn't help much either.

There's no hurry for this, but I think this issue should have even higher priority than #57, which is currently under "Active Review". Maybe you'd like to wait for the next co-chair meeting?

(Off topic: I'm nearly ready with MNX-Common by Example, Ties, and will then be starting on the Slur examples.)

[clnoel]

@notator Are you suggesting we put a section in the "Notational concepts" area to define systems before we define what their representational structure is? I guess I can see that, but I feel like #57 is the place where we are creating that definition.

I agree that redefining the part definition might be good, especially as there is, in fact, confusion around how to distinguish between two parts that are printed on the same staff due to spacing/layout concerns. Defining it as applicable to a single performer does not allow for a divisi, and therefore is not really adequate.

However, I don't understand the problem that the part-staff and system-staff thing is solving. It doesn't solve a grouping problem and it doesn't solve a problem in the part description that is covered by this topic (it has nothing to do with defining which sequence of notes belongs in each part). It is actually pretty clear what a staff is from the current description. Maybe we need a "staff-type" enumeration to facilitate default staff definitions inside the part and overriding staff definitions in the layout structure, instead?

[notator]

@clnoel

Are you suggesting we put a section in the "Notational concepts" area to define systems [...]?

Yes. We need to define at least one structural layer (container element) in the XML between the "mnx-common" element (the score) and the list of "part" elements it contains. We all have to agree that a "system" container is going to be part of the container hierarchy before we can start talking about how to construct it and which functions it has. If the co-chair decides that such a "system" container is not going to be inserted, then we will have to think again about how to how to group concurrent Parts and find "a model for controlling pagination or system breaks" (#57). Its possible that we may also need to define a "page" container between the "mnx-common" element (the score) and the "system" element, but I think its better to avoid complexity if we can, and not to add solutions to problems we haven't got yet.

I don't understand the problem that the part-staff and system-staff thing is solving.

The problem is that the Spec needs two different staff classes even though the staves look the same in the score. When parsing the file, the two types come at different places in the XML, and they can't be read into the same object type. @joeberkovitz' Draft is incomplete here -- but very interestingly so! I, for one, have never thought about anything quite like it before. Its a very powerful idea. As the above discussion shows, it leads to a very flexible way to define Parts. (And we need to know what we mean by a Part before we can start talking about "groups of Parts", so this is part of the solution to the grouping problem.) The Spec's use of Sequences is a further interesting subtlety, but that's more of an implementation detail. I think @joeberkovitz was probably beginning to solve one of MusicXML's unsolved problems... Be that as it may: A system-staff is a staff, contained by a system, that contains voices that are defined in terms of Part IDs (i.e. pointers to Part objects). A part-staff is a staff, contained by a Part, that contains anonymous voices (i.e. voices that have no pointers to other Parts).

Hope that helps, -- James

[clnoel]

Ah, I see.

I have to say that I completely disagree with your approach. The arrangement and grouping of the parts into a score does not belong in between the score and the parts. The parts need to be autonomous and rearrangable. I believe it should be the role of the entirely separate score-layout structure to hold that information

<mnx>
    <score>
        <mnx-common profile="standard">
            <global>
                ...
            </global>
            <part>
                <part-name>Horn I</part-name>
                ...
            </part>
            <part>
                <part-name>Horn II</part-name>
                ...
            </part>
            <score-layout>
                ...
            </score-layout>
            <score-layout>
                ...
            </score-layout>
        </mnx-common>
    </score>
</mnx>

I'm willing to put the score-layout in global instead, but they don't belong above the parts themselves.

I see what you mean about the different needs, but I don't think we need full attributes that are different. Just reuse a staff-type in the part and in the layout. I think using the terms "part-staff" and "system-staff" will be confusing to users.

[bhamblok]

I also disagree with the approach of @notator. I'm already confused by "part-staff" and "system-staff" :-). On top of that, I think "Systems" should not be defined at all... We should define "system-break" and "page-break"-elements which can be optionally used to achieve page-layout, but which also can be easily ignored. (I think MEI is giving us a good example for that). Especially for music-notation-editing-software-implementations, which will be using MNX as a native format and where the user has not defined page-layout yet, system-elements are non existing and so cannot be used as a container for parts, staffs, sequences, voices, ... anything. The same for page-container-elements.

Off topic (and nitpicking): We should limit our technical language to xml-terminology. For example: @notator you are talking about classes and objects. So you are building software using an Object Oriented methodology. That is an implementation-specific methodology which might not be used by others. So, where you are talking about "pointers to Part objects", you could/should talk about "references to Part elements" or "Part nodes".

[notator]

For anyone joining this discussion late: The code snippet (in https://github.com/w3c/mnx/issues/185#issuecomment-638498152) above shows how @clnoel's proposal adds <score-layout> elements to the way the Spec is currently defined.

@clnoel Here's a clip from your code from https://github.com/w3c/mnx/issues/185#issuecomment-636932457 showing how you are proposing to define <score-layout> in terms of <system-layout>, <part-layout>, <group-parts>, <page-layout> and <system> elements. (We are still on-topic, talking about how to group Parts.)

<score-layout name="Full Score">
    <system-layout name="Grouped Parts">
        <part-layout part="Violin 1"/>
        <group-parts type="bracket">
            <part-layout part="Horn 1"/>
            ...
            <part-layout part="Horn 8"/>
        </group-parts>
        ...
        <part-layout part="Piano" type="Grand"/>
    </system-layout>
    <page-layout page-number="1">
        <system system-layout-id="Grouped Parts" start-measure-id=1 end-measure-id=4 show-name="Full"/>
    </page-layout>
    <page-layout page-number="2">
        <system system-layout-id="Grouped Parts" start-measure-id=5 end-measure-id=10 show-name="Abbreviated"/>
    </page-layout>
    ...
</score-layout>

@bhamblok's objection that

We should define "system-break" and "page-break"-elements which can be optionally used to achieve page-layout, but which also can be easily ignored.

applies just as much to this proposal as to my alternative (see below). The answer is that consuming applications can always ignore or alter layout information if they want to. We don't need to define <system-break> or <page-break> elements to do that. The important thing is that it must be possible to extract printable Parts easily.

@clnoel My main objection to your proposal, as it stands, is that the "Full Score" layout only has one <system-layout>, so all the systems in the full score have to have the same layout (i.e. contain the same parts). That's wasteful of space, and is not the way things are usually done. You could probably remedy the problem by defining a list of <system-layout> elements that can be referenced in the <system> elements. That could be a good solution for small scores in which the system layout doesn't change much, but in most larger scores the system layout changes for practically every system (so it might be better either to put a <system-layout> definition directly inside each <system> or simply merge the two elements, and define the layout as part of the <system> element). A problem with defining a whole list of <system-layout> elements is that you then either have to provide a new <group-part> definition for each <system-layout>, or you have to define the <group-part> element separately, and then reference it from each <system-layout>.

I'm about to upload a separate posting that contains my alternative proposal expressed as demo code. The current posting is long enough already, and it would better, for future reference, if my proposal had a separate link address, so please bear with me for a few hours...

[bhamblok]

@notator I apologize. It's indeed starting to become a long posting, and I was already missing the fact you both are defining <page-layout> and <system-layout> elements, in which the <system> element certainly has the right to exist!

[clnoel]

@notator These are example layouts. I am not proposing that the "Full Score" layout is necessary in any way. That particular layout was designed to be as spread out as possible and to give every part their own staff and to apply to every page. The other examples have more than one layout that apply on different pages, or even different systems on the same page. That point is irrelevant.

For most scores I deal with (lots of PVG Pop pieces), we would only need one or at most two system-layouts, depending on if the Voice staff should be hidden for that system. At that point it gets unwieldy to re-describe the same system-layout 5 times per page. However, I do get the point that it could be unwieldy for large symphonic scores that change per-page. So maybe having an option to include modular part-layouts would be useful for that. I'm willing to discuss refinements, and debating this versus your proposal.

@bhamblok This thread is long, and #57 is worse! We'll get there.

--Christina

[notator]

@clnoel I'm still working on a presentable version of my proposal. As you say: We'll get there in the end! It occurred to me that your proposal could have a way of saying that there is a new system, and that the new system's layout is the same as the one before. That might cut down on the number of system-layout definitions. Its quite possible that I'm just not understanding your proposal well enough at the moment, but I think its more important now that I get my alternative on the table. We can then discuss the pros and cons of both. I have no problem accepting your version if it turns out to be better.

[notator]

@clnoel Sorry about the delay. I think the penny has now dropped... The "presentable version of my proposal" is actually going to be a summary of this thread's conclusions that I'll post when I think we know what the conclusions are. This thread is so long that something of the sort is going to be necessary. Trying to formulate my current position meant a lot of hard thinking. I've come to two interesting conclusions:

• I was wrong in https://github.com/w3c/mnx/issues/185#issuecomment-638442224 in thinking that the container hierarchy is relevant to this issue. However (off-topic): I would still much prefer the notation (currently in <part> elements) in MNX-Common scores to be presented in a container hierarchy that looks like the one I use in SVG (score->page->system->staff->voice->notehead).
• I fully agree with the layout you presented in https://github.com/w3c/mnx/issues/185#issuecomment-638498152.

So lets take it from there. I'd like to discuss the order in which your layout elements are defined. You currently have:

<score-layout ...>
    <system-layout ...>
        <group-parts ...>
            <part-layout .../>
        </group-parts>  
    </system-layout>
    ... (page layouts that use system layouts)
</score-layout>

I think it would be better if this hierarchy were defined inside-out, so that identical <group-parts> elements can be used in different <system-layout>s My "ultimate conclusions" document currently contains a global <parts-declaration> object that contains a declaration of the parts (booklets) that are defined for the score, together with the <part-group> to which they belong (<part-group> is the same as your <group-parts> element. I prefer <part-group>. Would you mind changing?): My top level currently looks like this:

<mnx>
    <score>
        <mnx-common profile="standard">
            <parts-declaration>
               ...
            </parts-declaration>
            <global>
                ...
            </global>
            .... (parts)
        </mnx-common>
    </score>
</mnx>

The <parts-declaration> is rather like the list of required instruments that precedes the music notation in a score. An important aspect of this declaration is that it defines an ID, for each group and each part, that we can use when describing part->staff, part->voice or even part->notehead allocations inside <system-layout> elements. Here's an example:

<parts-declaration>            
    <part-group id="woodwind-group" bracket-type="brace" ... >
        <part id="fl1" part-name="Flute 1" ... />
        <part id="fl2" part-name="Flute 2" ... />
            etc. (more flute parts)
        <part id="ob1" part-name="Oboe 1" ... />
            etc. (more oboe parts, clarinet parts, bassoon parts)
    </part-group>
    <part-group id="brass-group" bracket-type="brace" ...>
        <part id="tp1" part-name="Trumpet 1" ... />
            ... etc. (more trumpets, horns, trombones, tubas)
    </part-group>
    <part-group id="percussion-group" bracket-type="brace" ... >
        <part id="perc1" part-name="Percussion 1" bracket-type="square" ... />
        <part id="triangle" part-name="Triangle" ... />
            ... etc, more percussion instrument parts (booklets)
         <part id="pno1" part-name="Piano 1" bracket-type="curly" ... />                        
    </part-group>
    <part-group id "hp-pno-group" bracket-type="brace" ... >
        <part id="hp1" part-name="Harp 1" bracket-type="curly" ... />
        <part id="hp2" part-name="Harp 2" bracket-type="curly" ... />
        <part id="pno2" part-name="Piano 2" bracket-type="curly" ... />                        
    </part-group>
    <part-group id ="strings-group" bracket-type="brace" ...>
        <part id="soloVn" part-name="Solo Violin" ... />
        <part id="tuttiVnI" part-name="Violins I" bracket-type="square"... />
            etc. (parts for Violins II, Violas, Celli and Double Basses)
    </part-group>
</parts-declaration>

Note that bracket-type attributes are defined for all the parts that can have more than one staff in the score ( "Piano 1", "Piano 2", "Harp 1", "Harp 2", "Percussion 1" and "Violins I" -- "Violins I" are sometimes divisi).

I think the above <parts-declaration> should precede a section containing re-usable <system-layout> definitions (that are each given an ID), and that the <system-layout> definitions should precede the <score-layout> definitions (that could use <system-layout> IDs to define page contents).

Hopefully, we're now back on the same page! :-)

There is a problem with <system-layout>, that arises because parts can be grouped differently per staff on different systems. Fortunately, I think we can postpone its solution until we know whether the co-chair is going to agree to defining <system-layout> or not. That means a different issue. The problem is that we need a way to label the staves properly. For example: One system might have a single staff that is for "SAT" (ideally with the letters 'S', 'A' and 'T' vertically above one another, and maybe the word "Choir" to the left of a bracket left of the column), while another system could have one staff each for 'S', 'A' and 'TB'. It may well be that 'S', 'A', 'T' and 'B' are defined to be separate booklets, so the part-name and part-abbreviation fields defined for each part in §6.11 are inadequate. Each <system-layout> element needs to contain its own staff labels.

[bhamblok]

I feel this is going in the right direction. I would like to empower @notator for the naming of <part-group> instead of <group-part>. Could we also include nested <part-group>'s in the spec? As in this example from the original "xmlsamples3.0"-library: "ActorPreludeSample.xml":

[clnoel]

@bhamblok I'm not tied to my naming scheme. I have no objection to moving to part-group. My bigger example in #57 has something like this in the "Condensed Score" score-layout, but in order to be specific about proposals, this would be represented in my current schema by:

<system-layout>
    ...
    <part-group type="bracket">
        <part-group name="Horns in F" type="curly">
            <part-group name="1\n2" type="chorded">
                <part-layout part="Horn I"/>
                <part-layout part="Horn II"/>
            </part-group>
            <part-group name="3\n4" type="chorded">
                <part-layout part="Horn III"/>
                <part-layout part="Horn IV"/>
            </part-group>
        </part-group>
        <part-group name="Trumpets in C\t1\n2" type="chorded">
            <part-layout part="Trumpet I"/>
            <part-layout part="Trumpet II"/>
        </part-group>
        <part-group name="Trombones" type="curly">
            <part-group name="1\n2" type="chorded">
                <part-layout part="Trombone I"/>
                <part-layout part="Trombone II"/>
            </part-group>
            <part-layout name="3" part="Trombone III"/>            
        </part-group>
        <part-layout name="Tuba" part="Tuba"/>
    </part-group>
    ...
</system-layout>

The syntax for doing the Trumpet label needs work, but it should be pretty clear for all the other ones.

@notator May I ask why you prefer to nest the notation itself inside the layout scheme? How do you envision representing multiple layouts with different page sizes, systems per page and measures per system without repeating the notes themselves? Or is that not one of your goals?

[clnoel]

Also, I can certainly see an inside-out definition working where (to use the example from @bhamblok's post above), we define the following instead:

<score-layout>
    <part-group-layout id="HornsTwoStaff" default-name="Horns in F" default-type="curly">
        <part-group name="1\n2" type="chorded">
            <part-layout part="Horn I"/>
            <part-layout part="Horn II"/>
        </part-group>
        <part-group name="3\n4" type="chorded">
            <part-layout part="Horn III"/>
            <part-layout part="Horn IV"/>
        </part-group>
    </part-group-layout>
    <system-layout id="CondensedBrass">
        ...
        <part-group type="bracket">
            <part-group layout-id="HornsTwoStaff">
            <part-group name="Trumpets in C\t1\n2" type="chorded">
                <part-layout part="Trumpet I"/>
                <part-layout part="Trumpet II"/>
            </part-group>
            <part-group name="Trombones" type="curly">
                <part-group name="1\n2" type="chorded">
                    <part-layout part="Trombone I"/>
                    <part-layout part="Trombone II"/>
                </part-group>
                <part-layout name="3" part="Trombone III"/>            
            </part-group>
            <part-layout name="Tuba" part="Tuba"/>
        </part-group>
        ...
    </system-layout>
    ...
    <page-layout page-number="1">
        <system layout-id="CondensedBrass"/>
    </page-layout>
    ...
</score-layout>

[notator]

@clnoel you asked

May I ask why you prefer to nest the notation itself inside the layout scheme?

I don't. I mistakenly thought you were wanting to do something like that! I think we both want to put the layout information directly inside <mnx-common>, just before <global> and the list of <part> elements (where the notation is):

<mnx>
    <score>
        <mnx-common profile="standard">

            <!-- our pre-performance layout information goes here -->            

            <!-- one or more "global" elements containing information
                 that is globally relevant to each <measure> in the score -->
            <global>...</global>
            ...

            <!-- one or more "part" elements containing notation information for each part -->     
            <part>...</part>
            <part>...</part>
            <part>...</part>
            ...
        </mnx-common>
    </score>
</mnx>

Note that MNX allows multiple scores to be defined in a <collection> element. This means that we could actually do some nifty scoping. :-) Here's an example, adapted from Example 6 in §6.1.3 of the Spec:

<mnx>
    <collection>
        <parts-declaration>...</parts-declaration>
        <score>
            <title>Movement 1</title>
            <mnx-common>
                <system-layout>...</system-layout>
                <system-layout>...</system-layout>
                <system-layout>...</system-layout>
                <!-- etc. more system-layout elements -->
                <score-layout>...</score-layout>
                <global>...</global>
                <part>...</part>
                <part>...</part>
                <part>...</part>
            </mnx-common>
        </score>
        <score>
            <title>Movement 2</title>
            <mnx-common>
                ...
            </mnx-common>
        </score>
    </collection>
</mnx>

To do this properly, my <parts-declaration> ought really to be broken up into two distinct layers: a declaration of the <part>s and a definition of the <part-group>s. Then the <part>s could belong to different <part-group>s in different movements of the piece.

[notator]

Looking again at @clnoel's demo of how to nest <part-group>s, scoping seems to be possible everywhere. The <part-group type="bracket"> inside <system-layout id="CondensedBrass"> could also have been defined outside the CondensedBrass, and referenced by an ID. It would then have been available for other <system-layout> elements to use.

    <system-layout id="CondensedBrass">
        ...
        <part-group type="bracket">
            <part-group layout-id="HornsTwoStaff">
            <part-group name="Trumpets in C\t1\n2" type="chorded">
                <part-layout part="Trumpet I"/>
                <part-layout part="Trumpet II"/>
            </part-group>
            <part-group name="Trombones" type="curly">
                <part-group name="1\n2" type="chorded">
                    <part-layout part="Trombone I"/>
                    <part-layout part="Trombone II"/>
                </part-group>
                <part-layout name="3" part="Trombone III"/>            
            </part-group>
            <part-layout name="Tuba" part="Tuba"/>
        </part-group>
        ...
    </system-layout>

[clnoel]

I would like to point out that I feel like the layouts will usually constructed in the files by the programs making the MNX file automatically, translating from whatever system they use internally to represent systems. I see them just re-iterating all the parts each time there's a new layout needed, rather than trying to figure out an optimal set of part-group-layout elements to create.

That said making it possible to hand-design the layouts by making reusable part-group-layout still seems worthwhile. Programmers usually like modularity and reusability. :)

[notator]

There's something wrong. In my <collections> example above I shouldn't be allowed to put the <parts-declaration> parallel to the <score> elements, because at that point we don't know which notation type they refer to. And (much worse) there's no way to include the full score and its parts in the file without duplicating all the parts' code. That's not only wasteful of file space, its also an error prone maintenance nightmare. I think the answer is probably to have multiple <score> elements inside <mnx-common>, and to declare and define the <part> elements before defining the internal <score>s. (I'd leave the outer <score> elements as they are. The file might contain a <score> that uses some other notation (turkish, asian, korean etc.) that has an <mnx-common> transcription or arrangement.) We would then have something like this:

<mnx>
    <collection>
        <score>
            <title>Study IV (CWMN)</title>
            <mnx-common>
                <part-definitions>
                    <part id="fl1" name="Flute 1" ...>...</part>
                    <part id="fl2" name="Flute 2" ...>...</part>
                    <part id="fl3" name="Flute 3" ...>...</part>
                    <!-- etc., more part definitions (notation)
                </part-definitions>

                <!-- layout info, valid for all scores (especially for parts) -->

                <score name="Full Score">
                    <part-group-definitions>...</part-group-definitions>
                    <system-layout>...</system-layout>
                    <system-layout>...</system-layout>
                    <system-layout>...</system-layout>
                    <!-- etc. more system-layout elements -->
                    <score-layout>...</score-layout>
                    <global>...</global> <!-- globals for the Full Score -->
                    <part-reference part-id="fl1" />
                    <part-reference part-id="fl2" />
                    <part-reference part-id="fl3" />
                    <!-- etc. all part-references -->
                </score>

                <score name="Flute 1 part">
                    <system-layout>...</system-layout>
                    <!-- etc. more system-layout elements -->
                    <score-layout>...</score-layout>
                    <global>...</global> <!-- globals for the Flute 1 part -->
                    <part-reference part-id="fl1" />
                </score name="Flute 1 part">

                <!-- etc., all the part "scores" (booklets) -->

            </mnx-common>
        </score>
        <score>
            <title>Study IV (Hamparsum)</title>
            <mnx-hamparsum>
                ...
            </mnx-hamparsum>
        </score>
    </collection>
</mnx>

Note that a by-product of this is that each part booklet gets its own <global> element. And, parts can contain special information that does not belong in the Full Score. Cues, for example.

[clnoel]

I disagree that we need multiple score elements. We just need multiple score-layout elements inside a score element, each of which references a subset of the parts. I do think grouping the parts into an element is helpful. I'm not sold on parts-description as a name.

Multiple scores within a collection should refer to multiple movements or sections of a larger work that can be logically separated, not different booklets for the same music.

[notator]

I disagree that we need multiple score elements. We just need multiple score-layout elements inside a score element, each of which references a subset of the parts.

There are several reasons why I think that having a separate scope for each score inside <mnx-common> is a good idea, but I don't want to spend too much time discussing the point. Lets agree to disagree for the moment. If, after reading my next posting, you still think your solution would be better than mine, we can come back to the question.

I'm not sold on parts-description as a name.

I think you meant "parts-definitions" there. If so: I'm not much sold on it either. I just wanted to emphasise that the enclosed <part> elements were the definitions that are in the spec. I think a better name would simply be <parts>:

<parts>
    <part id="fl1" name="Flute 1" ...>...</part>
    <part id="fl2" name="Flute 2" ...>...</part>
    <part id="fl3" name="Flute 3" ...>...</part>
    <!-- etc., more part definitions -->
</parts>

Multiple <score>s within a <collection> should refer to multiple movements or sections of a larger work that can be logically separated, not different booklets for the same music.

I agree with the first part of that sentence, but dont understand the second part. Here's how to write multiples within a` that refer to multiple movements or sections of a larger work that can be logically separated:

<mnx>
    <collection>
        <score>
            <title>Symphony, Movement 1</title>
            <mnx-common>...</mnx-common>
        </score>
        <score>
            <title>Symphony, Movement 2</title>
            <mnx-common>...</mnx-common>
        </score>
        <score>
            <title>Symphony, Movement 3</title>
            <mnx-common>...</mnx-common>
        </score>
    </collection>
</mnx>

I'm proposing that it should be possible to define <score>s for the same music (e.g. Full Score, instrumental parts, rehearsal scores, arrangements etc.) inside each <mnx-common> element. That's in addition to being able to define different music in different <score> elements inside <collection>. Note that each score inside an <mnx-common> element has the same number of measures.

---

I've been working to improve the code sketch in my previous posting, and think I've now got a good, complete answer to the question of how to group parts. The proposal is rather long, so I'm going to put it in a separate posting. I'm also tracking issues and proposed changes to the spec, that result from this thread, in a separate document. Will come back to those later.

[notator]

How to group parts - a proposal

I'm using the following conventions:

• lowercase Camel case for all element and attribute names. XML naming conventions weren't so clear in the 1980s when MusicXML started out, but I think the use of '-' characters in names is now widely deprecated. See, for example, https://www.w3schools.com/xml/xml_elements.asp ("Best Naming Practices" and "Naming Styles"). §4 of the Google XML Document Format Style Guide insists on lowercase Camel case.
• There's a containing element around lists of similar elements, especially where the list is potentially rather long. XML was designed to be both machine and human readable, and modern tools for editing XML allow such container elements to be collapsed for a better overview of the file. I first came across this convention when working with capella's CapXML. It can be very useful.

---

Here's my current proposal for the general structure of an <mnx-common> element. The component elements are described in further detail below.

<mnx-common>
    <!-- like the globals defined in §6.1.7 in the current spec -->
    <globals>
        <global>...</global>
        <!-- etc., more global definitions -->
    </globals>

    <!-- like the parts defined in §6.1.7 in the current spec -->
    <parts>
        <part id="fl1" name="Flute 1" >...</part>
        <!-- contains <measure>s etc. -->
        <part id="fl2" name="Flute 2" >...</part>
        <part id="fl3" name="Flute 3" >...</part>
        <part id="pno" name="Piano">...</part>
        <!-- etc., more part definitions -->
    </parts>

    <!-- global systemLayout-definitions (optional) -->
    <systemLayouts>
        <systemLayout id="globalSysLayout1">... </systemLayout>
        <systemLayout id="globalSysLayout2">... </systemLayout>
        <systemLayout id="globalSysLayout3">... </systemLayout>
        <!-- etc., more global systemLayout definitions -->
    </systemLayouts>

    <!-- all the scores in this mnx-common element -->
    <scores>

        <score name="Full Score">
            <!-- optional globals for the full score  -->
            <globals>...</globals>
            <!-- systemLayout-definitions for the full score  -->
            <systemLayouts>
                <systemLayout id="fullScoreSysLayout1">...</systemLayout>
                <systemLayout id="fullScoreSysLayout2">...</systemLayout>
                <systemLayout id="fullScoreSysLayout3">...</systemLayout>
                <!-- etc. more systemLayout elements -->
            </systemLayouts>
            <!-- scoreLayout for the full score -->
            <scoreLayout>...</scoreLayout>
        </score>

        <score name="Flute 1 part">
            <!-- optional globals for the flute 1 part -->
            <globals>...</globals>
            <!-- systemLayout-definitions for the flute 1 part -->
            <systemLayouts>
                <systemLayout id="flute1SysLayout1">...</systemLayout>
                <systemLayout id="flute1SysLayout2">...</systemLayout>
                <!-- etc. more systemLayout elements -->
            </systemLayouts>
            <!-- scoreLayout for the flute 1 part-->
            <scoreLayout>...</scoreLayout>
        </score>

        <score name="Flute 2 part">...</score>
        <score name="Flute 3 part">...</score>
        <!-- etc., all the part "scores" (booklets) -->
    </scores>
</mnx-common>

The <globals> element

The <globals> element contains a list of <global> definitions. These are the <global> elements, as defined in §6.1.7 and §6.1.8 in the current spec.

The <parts> element

The <parts> element contains a list of <part> definitions. These are the <part> elements, (nearly) as defined in §6.1.7 and §6.1.9 of the current spec. Each of the <part> elements has an id and a name attribute. (The name attribute is probably redundant.) The <part><part-name> and <part><part-abbreviation> elements defined in §6.11 of the spec are redundant because I'm naming staves (not parts) in <score><systemLayout><staffGroup><staff> elements (see below). The Spec's <part><instrumentSound> element needs to be discussed in a separate issue. Note that <part> definitions can use multiple staves (they can have <measure><sequence> staff attributes) but that the bracket printed to the left of a system is defined in the <systemLayout><staffgroup> that uses the <part> (i.e. not in the <part> definition). Here's how <parts> looks in more detail:

<parts>
    <part id="fl1" name="Flute 1">
        <measure>...</measure>
        <measure>...</measure>
        <measure>...</measure>
        <!-- etc. more measures -->
    </part>
    <part id="pno1 name="Piano 1">
        <measure>...</measure>
        <measure>...</measure>
        <measure>...</measure>
        <!-- etc. more measures -->
    </part>
    <part ... >...</part>
    <!-- etc. more parts -->
</parts>

The global <systemLayouts> element

This is an optional element that contains a list of <systemLayout> elements that can be used by any of the scores in scope. It has the same structure as the <score><systemLayouts> element (described below). A simple <systemLayout>, having a single staff with no name to its left could, for example, be defined here for all part scores (booklets).

The <scores> element

This contains a list of all the scores in this <mnx-common> element. Note that:

• All the scores in this <mnx-common> element have the same number of measures.
• The <mnx><collection> element can contain more than one <score><mnx-common> element, so this file could contain different "movements" of the same piece defined there.

  <scores>
  <score name="Full Score">... </score>
  <score name="Flute 1 part">... </score>
  <score name="Flute 2 part">... </score>
  <score name="Flute 3 part">... </score>
  <score name="Piano part">... </score>
  <score name="Full Score arranged for piano">... </score>
  <score name="Full Score arranged for choir and piano">... </score>
  <!-- etc. all the scores -->
  </scores>

The <score> element

The basic structure looks like this:

<score name="Full Score">
    <globals>...</globals> <!-- optional "global" elements, like §6.1.7, but special to this score -->
    <systemLayouts>...</systemLayouts> <!-- see below -->
    <scoreLayout>...</scoreLayout> <!-- see below -->
</score>

The <systemLayouts> element

Contains a list of <systemLayout> elements. These can be referenced (and used in any order) by the local <scoreLayout> element.

<systemLayouts>
    <systemLayout id="fullScoreSysLayout1">...</systemLayout>
    <systemLayout id="fullScoreSysLayout2">...</systemLayout>
    <systemLayout id="fullScoreSysLayout3">...</systemLayout>
    <!-- more systemLayout elements
</systemLayouts>

The <systemLayout> element

A <systemLayout> is a list of <staffGroup> elements in top-to-bottom order. The <staffGroup> bracket attribute determines the shape of the bracket, to the left of the system, enclosing the <staffGroup>. The <staffGroup> barline attribute decides whether or not a barline should be drawn through the whole <staffGroup> (The barline's type is decided elsewhere).

<systemLayout id="sysLayout1" staffLabelsTextAlign="center">
    <staffGroup name="woodwind" bracket="brace" barline="yes">...</staffGroup>
    <staffGroup name="brass" bracket="brace" barline="no">...</staffGroup>
    <staffGroup name="percussion" bracket="brace" barline="no">...</staffGroup>
    <staffGroup name="soloPiano" bracket="curly" barline="yes">...</staffGroup>
    <staffGroup name="strings"bracket="brace" barline="yes">...</staffGroup>
    <!-- more staffGroup elements -->
</systemLayout>

The <staffGroup> element

[begin Edit 12.06.2020] Added displayName attribute to <staffGroup>. When present and equal to "no", this makes the name attribute invisible. [end Edit 12.06.2020

Parts are being grouped here by staff. The staves are grouped by system, the systems by page and the pages by score (see below). <staffGroup> elements can nest. The innermost level is a list of <staff> elements that reference <part> elements by ID. Note: I have never seen a full score containing staves that have more than two voices per staff, except perhaps in staves belonging to the same part. Here is how @bhamblok's example at https://github.com/w3c/mnx/issues/185#issuecomment-639477071 would be coded (with each of the horns in a separate voice on the two staves, but with trombones 1 and 2 in the same voice -- possibly notated as 2-part chords):

<staffGroup name="brass" bracket="brace" barline="no" displayName="no">
    <staffGroup name="Horns in F" bracket="curly" barline="yes">
        <staff name="1\n2">
            <voice partIDs="hn1" />
            <voice partIDs="hn2" />
        </staff>
        <staff name="3\n4">
            <voice partIDs="hn3" />
            <voice partIDs="hn4" />
        </staff>
    </staffGroup>
    <staffGroup name="Trumpets in C" bracket="none" barline="yes">
        <staff name="1\n2">
            <voice partIDs="tp1 tp2" />
        </staff>
    </staffGroup>
    <staffGroup name="Trombones" bracket="curly" barline="yes">
        <staff name="1\n2">
            <voice partIDs="tb1 tb2" />
        </staff>
        <staff name="3">
            <voice partIDs="tb3" />
        </staff>
    </staffGroup>
    <staffGroup name="Tuba" bracket="none" barline="yes">
        <staff name="">
            <voice partIDs="tubaID" />
        </staff>
    </staffGroup>
</staffGroup>

[begin Edit 12.06.2020] - new version of the Solo Piano <staffGroup>

A Solo Piano <staffGroup> looks like this:

<staffGroup name="Piano" partID="soloPianoPartID" bracket="curly" barline="yes" />

The number of staves and voices depends on the Solo Piano's <part><measure><sequence> elements. Note that the number of staves and/or voices is not part of the <systemLayout> definition, and can change for each use of the <systemLayout> to which this <staffGroup> belongs. There needs to be an option somewhere, that determines whether the number of staves can change per <measure> (i.e. during the course of a <system>) or not. (As always, solutions to problems like this need to be tested by an MNX-Common by Example example.)

[end Edit 12.06.2020]

The <scoreLayout> element

This element is a list of <page> elements, each of which contains a list of <system> elements. <score-layout> could actually be re-named <pages>:

<scoreLayout width="500px" height="707px" margins="30px"> <!-- for printing on portrait A3 or A4 -->
    <page>
        <systems>
            <system startMeasureNumber="1" systemLayoutID="sysLayout1" />
            <system startMeasureNumber="6" systemLayoutID="sysLayout1" />
            <system startMeasureNumber="10" systemLayoutID="sysLayout1" />
            <system startMeasureNumber="13" systemLayoutID="sysLayout2" />
            <system startMeasureNumber="18" systemLayoutID="sysLayout1" />
            <!-- etc. more systems -->
        </systems>
    </page>
    </ etc. more pages -->
</scoreLayout>

Notes:

• The <page> element could have an optional index attribute (like the Spec's <measure> element), but I think that's a mistake in both cases. Such indices can be deduced from the list of <page> (or <measure>) elements. I think that stipulating page numbers is a maintenance problem.
• The width/height proportion can be different for the score and parts (they have different <scoreLayout>s).
• If this score is printed on paper that does not have the same width/height proportion as the A-series, then it will either have wider left and right margins or wider top and bottom margins.
• This <scoreLayout> definition does not stipulate fonts or font sizes. It simply assumes that consuming applications will be able to find settings for those that allow all the systems to have the same width, and to have heights that allow them to fit vertically on the given pages. Applications can, of course, ignore the given page breaks, and provide their own. An important application of this freedom is the writing of scores on a single page that has unlimited height (a "scroll" score). Such scores are useful for viewing on screens.

---

It would be quite straightforward to translate this proposal into a formal XML-Schema . That might be easier to track than the current spec's approach of defining different element types in different sections of the Spec.

Feedback and suggested changes welcome, of course!

[clnoel]

I think I'm with you on most of this, @notator. Here's the tweaks that I see:

• Like my previous suggestion, but now understanding your response, I suggest that the name of the <score> elements should be differentiated since they have entirely different content. Here I suggest that we have a hierarchy that goes like the following, and brings this closer to my initial proposal:

  <mnx>
  <collection> 
      <score>
          <mnx-common>
             <!--globals & parts-->
             <scoreLayouts> <!--same as your scores element above-->
                <systemLayouts>...</systemLayouts> <!--global system layouts-->
                <scoreLayout> <!--same as your score elements above-->
                      <systemLayouts>...</systemLayouts>
                      <pages>...</pages>   <!--grouped page elements as you describe above-->
                <scoreLayout/>
                <!--more scoreLayout elements-->
             </scoreLayouts>
          </mnx-common> 
      </score>
      <!--more score elements-->
  </collection> 
  </mnx>

• I dislike not being able to put a staff directly into a systemLayout. Your current version only allows for staffGroup inside those. Is there a reason for that?
• The scoreLayout page size should not be forced to pixels (I don't know if you intended that!). I suggest looking into the units supported by SVG.

Overall, I think I like this, though. It's very similar to what I was picturing with my layout, and solves the Trumpet in C label problem that I had with the given example. And, honestly, fits very nicely into the scheme we use at Musicnotes to provide system layouts on our files, which I really like.

[notator]

Yes, there's something not quite right about having an element called <score> at two levels in the XML container hierarchy. But I'm unhappy about calling the inner one a <scoreLayout>. Its a printable object, not just a layout definition. And I prefer short, simple names (when they are not confusing).

This needs to be debated in a separate issue.

But hows about renaming the outer <score> instead? We are proposing changes to §6.1.3 The collection element anyway: We now have <part>s defined inside <mnx-common>, so the <collection> "parts" type is redundant. I think the outer <score> element could be renamed <book>. (A "score" is a sub-class of "book"). Then we could have a <collection type="text"> that would be a text (like the booklet in a CD) that provides ancillary information about the score. The text could, for example, contain links to related documents on the web. I don't think such info belongs in a score's metadata. Metadata should be self-contained info that only relates to the score itself. [begin Edit 13.06.2020] For the new issue: If the outer <score> element were to be renamed <book>, then the <collection> element itself could be renamed <books> -- which is both shorter and more precise. :-) Do <collection> elements really need to be nestable? [end Edit 13.06.2020]

---

I see no fundamental objection to mixing <staff> and <stafGroup> elements inside <system-layout> elements. Do you want/need to add any (optional) attributes to the <staff> element for such cases? Perhaps you could provide an example? Maybe there are a lot of cases where its just simpler.

---

I have to admit that the pixel dimensions on the <scoreLayout> (=<pages>) element were deliberate. I wanted to flag that this is something that needs to be debated (but in a separate issue). There's a lot that can be learned from SVG's viewbox approach to dimensions. Essentially, the viewbox uses dimensionless units that are treated as pixels by default. The actual size of a printed SVG depends on the magnification factor, and is independent of the size of the screen or paper on which it is being displayed. (See also the notes below <scoreLayout> in the above proposal.)

---

I think we basically now agree on how to group parts, so I think we should try to pause this thread until the chair has had a chance to review it at their next meeting (Tuesday 23 June 2020). Apart from finishing my implementation of ties, I'm going to be revising the writing of XML Schemas. There's plenty to be getting on with. :-)

[adrianholovaty]

Thanks for all of this discussion, everybody. We (group co-chairs) have decided to tackle this as our next focus for the "MNX-Common By Example" page. I will synthesize the proposals in this issue and put together a pull request for people to react to.

(To be clear, I mean the specific issue of grouping parts. The discussion on this issue has naturally expanded into other areas, and I encourage people to go to the other open issues, to keep things relatively organized: #188 #34 #57.)

@notator Would you mind duplicating the relevant parts of your proposal into these issues, so that we can keep things organized? Here are the other issues: #188, #34, #57