Co-chair meeting minutes: May 30, 2024

MNX

In our last meeting we discussed changes to cautionary accidentals in order to focus on encoding their appearance rather than their semantics, and Adrian has now implemented this via a new enumeration in accidental-display, allowing us to encode that an accidental should be parenthesised or bracketed (commit). There will be more work to do in this area in future concerning encoding the reason for the accidental’s appearance, but we will return to that in future.

We also discussed the need to specify whether a MNX document encodes the display of accidentals, and Adrian plans to move on to this next, preparing a pull request for an initial implementation of a new supports object, which will form the beginning of a general-purpose way of describing the approach to encoding.

Adrian has also made a few improvements to the doc generator tool, including ensuring that Windows newline characters are removed (issue #338), and changing the way the raw JSON file that holds the metadata for the format such that it uses a list of strings, removing new lines from the file and making it easier to read diffs (issue #340). Adrian will make the corresponding change for the MusicXML repository as well.

Adrian also fixed some remaining kebab case values to change them to camel case for the barline-type object (issue #342). A similar change needs to be made for the octave-shift values for octave lines (issue #344), which Adrian will do in due course.

Discussion #343 raises an issue concerning how we encode the staff on which a clef should appear for a multi-staff part, and indeed how in general sequences, events, and notes are assigned to staves. We already have a staff index for parts and sequences, but we will need to add this to both events and notes in order to provide full flexibility in encoding voices, chords, and individual notes that can be assigned to another staff. Adrian will prepare a proposal for this, with some worked examples for multi-staff instruments.

MusicXML

Werner Lemberg has opened discussion #518 concerning the encoding of enclosures in directions. Myke proposes that we specify that sibling directions within the same element with the same enclosure type should share a single enclosure, unless a new putative enclosure-break attribute is set; this attribute would be of yes/no type and default to no. Ideally, we would specify enclosure on the higher-level direction element if it is intended that all of the child elements should be enclosed, but because the current default usage of enclosure on the first child element of direction-type assumes that the enclosure will be inherited by each subsequent child, this feels like too big a change. We welcome further community discussion in discussion #519.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 20 June 2024.