Multi-part & Single-part directions on multi-part staves

[clnoel]

Where should a direction that applies to all parts in a multi-part staff be displayed? What about directions that only apply on multi-part staves (like the unis. label in our mid-system layout example)? What about directions that only apply to one part of a multi part stave, like directing the sopranos to be quiet and the altos to be loud? For that matter, what about lyrics, which might sometimes be the same for the parts and sometimes will be different? (Some of this seems to be covered in #196, but I don't feel like they are exactly the same).

Note: This question is carried over from https://github.com/w3c/mnx/issues/185#issuecomment-948018127, where it was labeled out-of-scope topic B. Here is the appropriate place to discuss this.

Here are some reference images that have labels/directions that do not apply to individual parts, but do apply to a multi-part staff, or have a direction that applies to several staves and only appears once. These come from #185 and #104

Example 1: The dynamic markings in the first system and the "unis." label in the third system:

Example 2: The part labels:

Example 3: The line going from the half-note in the fifth measure to the whole note in the sixth measure:

I do not at this time have a proposal, but it's probably going to involve directions in <global> or in the <part> descriptions and child elements of system saying where they go. I don't see them being a part of system-layout, which is designed to be reusable, but maybe it'll have to be as we get down into it.

--Christina

[clnoel]

Here's another example, showing both the expanded and reduced score (see https://github.com/w3c/mnx/issues/185#issuecomment-956337091 )

Note that in this example, there are div directions that appear differently in the expanded and reduced scores, and that the tenor part gets a clef change.

---

I proposed in the other issue that <clef> be allowed in <staff-layout> elements, but @cecilios and @joeberkovitz had a better idea:

@cecilios said:

Allowing to define the clef in the staff-layout is a partial solution, only valid when the clef does not change along a system. It doesn't allow to deal with intermediate clef changes for one of the voices. Also, it looks ugly for my taste.

What if we add an attribute to <clef>, e.g.: <clef layouts="Soprano1 Soprano2">, to restrict the element to be meaningful only when any of the referenced layouts are used?. In your example, this would require to define a clef for each layout. e.g.:

<part>
    <measure>
        <directions>
            <clef sign="G" line="2" octave="-1" layouts="lay1 lay2"/>
            <clef sign="F" line="4" layouts="lay3"/>
        </directions>

This solution can, perhaps, be extended to other elements requiring this.

When I objected that this would be tying the layouts too closely to the semantic parts, @joeberkovitz said:

While it's desirable to partition layout info into a separate <score> element, that doesn't mean that there can't be elements in <part> that relate to layout. @cecilios suggestion about encoding clefs that are specific to certain layouts is one example. What's perhaps not so great though, is to allow two-way references between layouts and music content, where layout elements refer to music content IDs and music content refers to layout IDs. That becomes very messy and hard to validate.

I wonder if something analogous to the HTML/CSS class= attribute would help out here: an arbitrary label slapped onto semantic content, that layouts can refer to, e.g.

<part>
    <measure>
        <directions>
            <clef sign="G" line="2" octave="-1" class="reduced"/>
            <clef sign="F" line="4" layouts="expanded"/>
        </directions>

and elsewhere, one or more part layouts that indicates what classes are being selected for use in a layout:

        <part-layout part="soprano" class="reduced">

This is a crude proposal and has holes but hopefully conveys the idea: classes are a neutral set of IDs that serve to connect any number of layouts with any number of semantic elements, without everything referring to everything else.

I believe that this proposal has merit for directions in general, and maybe a lot of our other sticky places.

--Christina

[cecilios]

I agree. @joeberkovitz idea of indirect linking is a much better solution.