Handling of Mensurstrich and related issues

[mscuthbert]

(background: https://en.wikipedia.org/wiki/Mensurstrich)

Mensurstrich is a very common way of transcribing medieval and Renaissance music into CWN -- it is 99% CWN so not its own variant but it has several common features that have been hard to express in MusicXML

MusicXML and Finale support the barline value of Mensurstrich (https://usermanuals.musicxml.com/MusicXML/Content/ST-MusicXML-group-barline-value.htm) which is one aspect of the notation but not the one that is most difficult to deal with.

In editions using Mensurstrich in order to further deemphasize the barline, it is customary to put the full value of the note that crosses a barline in the bar where it begins and to position notes in the following bar(s) later, as in measures 3-4 of the bassus in the Wikipedia example:

https://en.wikipedia.org/wiki/Mensurstrich#/media/File:Josquin_Domine_ne_in_furore.svg

Supporting this + the barlines only between staves would be the minimum requirement for Mensurstrich support. There is one other important consideration however -- when the following measures are on another system, it is customary to show the residual value as a note in parentheses (sometimes tied backwards), as in system 2-3 of this edition:

This edition of Bach's Musical Offering from the Gesellschaft edition shows a common feature found in some Mensurstrich and 19th c. editions: the dot of a dotted note is placed where the note would be if it were tied:

I can see two possible encoding options. One is to have the user encode the values as written with notes in following measures displaced as to alignment (and performance). The other is to encode all the notes as they would be in other CWN scores but give a style preference that states they should be rendered as Mensurstrich values. The latter is simpler to add to MNX and probably easier for rendering agents even but distorts the original, multiplying notes that were singular in their original sources into multiple notes in the transcription. As far as using MNX as a substitute for MEI and other encoding frameworks for critical editions, the former is preferred.

[clnoel]

My suggestion is that we do the following for notes that cross a measure boundary:

1) Specify the written note with an event value of the time left in the first measure, a display style of the visible note, and the beginning of a non-printing tie. 2) Specify an additional note in the next measure with an event value of the note's remaining time, a Mensurstrich display style, and the end of the tie.

A program interpreting this will know that a note with the Mensurstrich display style is only printed at the beginning of a system,.

We also add a barline style for Mensurstrich that means it is printed across lyrics not staves.

Here's how measures 3-4 of that Wikipedia example might look:

<measure barline="Mensurstrich">
  <sequence>
    ...preceding notes...
    <event value="/4">
      <note pitch="C3"/>
    </event>
    <event value="/2" style="layout-value: /1">
      <note pitch="G3">
        <tied target="id2" style="display: none"/>
      </note>
    </event>
  </sequence>
</measure>
<measure barline="Mensurstrich">
  <sequence>
    <event value="/2" style="display: Mensurstrich; parens: true">
      <note pitch="G3" id="id2"/>
    </event>
    <event value="/2">
      <rest/>
    </event>
  </sequence>
</measure>

For the piece with odd dot, we need to change the display of the note to a dot.

[mscuthbert]

Similar issues arise for the frequent case of tuplets extending over barlines where the composer has chosen not to use ties to ensure that each measure has the exact right duration. Such cases are quite common.

[shoogle]

@clnoel's example is good, but I'm not sure there is a need to specify layout-value that is separate to value. I'd prefer just to specify the note's full duration as value and leave it up to the application to work out that it crosses the barline. (We might want to use something like layout-value for other cases where you just want a particular note to be displayed with a different notehead.) It is not strictly necessary to put anything in the following measure, but I can see that it might be a good idea to give some kind of clue that there is something leftover from the previous measure.

I would prefer to see residual notes and ties, and placement of residual dots, handled through global styles:

• showResidualNotesAfterSystemBreak
• showResidualDotsAfterBarlines

This has the advantage that the user can easily choose to enable or disable them depending on their personal preference. This is appropriate for new compositions, but I can see that there is an encoding advantage to being able to specify that a particular historic edition did in fact show a residual note in a particular measure. Perhaps there should be a way to encode that information for the benefit of people who are interested in that sort of thing (i.e. academics) but have its display in consumer applications controlled by the style setting.

[clnoel]

Part of the point of specifying both value and layout-value is so that programs that check for underfilled or overfilled measures will not produce an error case. In my example, each measure is exactly full with 4 beats of music.

[shoogle]

That looks helpful at first glance, but in reality it is not as helpful as it seems. Imagine a note has a value and layout-value that are different, but there is no corresponding gap at the beginning of the next measure. If the program just trusts the layout-value without also checking the value then it gets 4 beats in the first measure and 4 beats in the second. However, if it ignores the layout-value and just adds up the values then it will correctly see that the total for both measures is not 8 beats. Since the program has to look at both measures anyway, it may as well calculate the layout-value on its own.

Similarly, there is no need for the second measure to say that there are some beats left over from the previous one: instead it can just include fewer of its own beats, thereby forcing programs to look back at the previous measure to see if anything is carried over. However, the application can't stop at the previous measure: it may need to go back and look at all previous measures just to check that everything adds up. Also, if something didn't add up then the application would have no way of knowing where the mistake is.

So there is an advantage to including some kind of hint that a measure contains extra beats. This can either be done by having a layout-value on the final note of the first measure, or a carried-over value at the beginning of the second measure, but there is no advantage to having both.

[clnoel]

You are correct that there is "no need".

But I was thinking about this from a profile standpoint. Read here for a list of profile-constraints that I had been putting together around the time that I was discussing this topic. My method meets the complete-measure constraint, and your method does not. Therefore it is likely that more consumers will be able to correctly interpret and layout my solution here.

However, a "looser" profile might be more appropriate for Mensurstrich notation anyway. We should think about that. --Christina

[shoogle]

The requirement you give for a complete-measure profile is:

complete-measures: Each measure exactly fills out its duration in every part. [...] Also, no sequence can have a duration longer than the measure's duration

I would argue that, by definition, Mensurstrich notation does not meet this requirement, so we shouldn't try to force it to do so.

Put another way, what would you use an incomplete-measures profile for, if not for Mensurstrich notation?

If you did want to "squeeze" Mensurstrich notation into the standard profile, then the way to do this would be to swap the value and layout-value (and rename layout-value to display-value) so applications don't have to do anything extra to support it.

In other words, rather than treating the minim that crosses the barline as a "minim with the layout of a crotchet, with optional tie at a section break", instead treat it as "two actual crotchets with the option to display them as a minim". This allows applications to show something sensible even if they don't know how to deal with Mensurstrich notation, but I think a better solution overall is to put it in its own profile where such display hacks are not required.

[clnoel]

We don't need an incomplete-measures profile restriction, I don't think, because that would just be a lack of a complete-measures restriction. The other reason for incomplete measures is for places where there is no time-signature and therefore no way to tell how many beats belong in a measure. But you are also right that Mensurstrich does not naturally fit into complete-measures.

So, (and this is me changing my mind, I think?) do we want to stop trying to find a way? Or do we want to come up with at least a style recommendation for those who are trying to represent Mensurstrich in a limited program?

--Christina

P.S. I fail to see the difference between what I coded and what you recommend (other than renaming the property). I did code two tied half-notes (value="/2"), which are visually replaced by a whole note (layout-value="/1") under most circumstances.

[shoogle]

We don't need an incomplete-measures profile restriction, I don't think, because that would just be a lack of a complete-measures restriction.

Maybe, but I wonder whether it would be better to use profiles as a way to opt-in to supporting extra features. That way complete-measures would just be the default profile (since it is the simpler case) and applications would opt-in to supporting more complicated features like mensurstrich/incomplete-measures.

do we want to stop trying to find a way? Or do we want to come up with at least a style recommendation for those who are trying to represent Mensurstrich in a limited program?

I think we have presented some clear alternatives:

1. Properly support Mensurstrich notation
   • This requires additional effort from applications so it would probably have to be an optional feature.
   • We could provide a fallback mechanism so that applications that don't support it still show something sensible, though this might be more trouble than it is worth.
2. Use tricks like swapping noteheads
   • This is easier for applications but puts the onus on end users to ensure that durations add up properly.
   • It also non-semantic, which risks Mensurstrich notation being confused with other forms of notation that require noteheads to be swapped.

Now it is for other parties to say what they think. However, @mscuthbert made an interesting point about tuplets crossing barlines being similar to Mensurstrich notation but more common. The two cases are probably similar enough to share a solution (i.e. be in the same profile). The tuplet case might even be considered common enough to go in the default profile, so maybe Mensurstrich notation can too?

P.S. I fail to see the difference between what I coded and what you recommend (other than renaming the property). I did code two tied half-notes (value="/2"), which are visually replaced by a whole note (layout-value="/1") under most circumstances.

Quite right! That was me getting confused by the /X notation rather than 1/X. I was already aware of the /X shorthand but forgot about it on this occasion. I'm not a fan of it for this reason.

[mscuthbert]

I think that one of the main advantages of MusicXML as it currently is over MEI (which supports more notational systems in theory) is that people using MusicXML to encode things beyond what is supported by most user agents (notation software, etc.) get a decent "notes rests and measures" fallback. I hope that we continue this trend in MNX, so that whatever encoding of Mensurstrich we choose we can get something that looks like and parses like CMN to readers who don't have a clue about Mensurstrich. I like no. 1 as better than no. 2, but think that we might do something like encoding (in pseudo-code, not MXN) a half note on the last quarter of the bar as something like: or something like that. then if all the mensurstrich-* are ignored by the user agent, we still get quarter-tie-barline-quarter which would be fine.

[clnoel]

@mscuthbert

a half note on the last quarter of the bar as something like: or something like that.

Are you missing a code mark-down for your example? I'd like to see it