Co-chair meeting minutes: December 30, 2025

MNX

We discussed some of the issues and discussions that have been raised by members of the community in the last little while:

• Discussion #469 proposes that the measures object in part should be mandatory, and should have the same number of items as the global measures object; we agree, and will make this change.
• Discussion #467 asks what a consuming application should do when mnx.supports.useBeams is set to false, but beams are encoded in the document anyway. For the moment, we will recommend that if useBeams is false, the consuming application can decide whether any encoded beams in the document should be respected. In the future, we foresee the need to specify strategies for beaming at the level of time signature/meter or measure, so that documents can encode only beaming overrides (places where notes should be explicitly unbeamed or beamed); we will return to this in future.
• Discussion #472 asks for clarifications concerning how sequences and beams interact. The general principle is that beams should only reference events from the same sequence, except in the case of beams that cross barlines, in which case, the sequences will be different but must belong to the same part voice.

Next meeting

The next co-chairs meeting is scheduled for Monday 12 January 2026.

Co-chairs meeting minutes – December 2, 2025

MusicXML

We discussed the candidates for the MusicXML specification editor position, and both the depth and quality of commitment of this community to MusicXML impressed us and warmed our spirits. The co-chairs will be contacting candidates in due course to discuss next steps.

MNX

We continued to discuss tempo markings (issue #113) following our discussion in the previous co-chairs meeting. We decided that swing or rhythmic feel markings, despite often being displayed in line with tempo markings, or sometimes in place of them, are sufficiently different from tempo marks as to be encoded using a separate object, which we will return to in future.

After much discussion, we arrived at a proposal for a minimal representation of tempo: a label, defined as a simple string; and the tempo value, defined as a note value unit and a numeric value, both of which are optional. We’ll assume that consuming applications will be able to construct a default displayed appearance for the tempo item using either or both of these values. To make it possible to specify precisely how the tempo should be displayed, we propose adding an optional rich text object, which can define the displayed appearance. We propose extending the formatted text item to define references to other objects, so it’s possible to reference the label and tempo value data in order to avoid redundantly encoding the same values in two places.

We welcome feedback on this proposal, which you can read here.

Next meeting

The next co-chairs meeting is scheduled for Tuesday 16 December 2025.

Co-chairs meeting minutes – November 18, 2025

MNX

With regard to the proposal for formatted text (discussion #459), the co-chairs plan to go ahead with the current proposal. We’re grateful for the feedback we’ve already received, but of course welcome more from the community. The next question is where this formatted text will first be used in the specification.

We spent the majority of the meeting discussing how we might extend the specification of the tempo object to use formatted text for the presentation of tempo marks. We think adding a text property to the tempo object is uncontroversial, but the approach for how to encode the visual appearance of metronome marks raises issues that we want to discuss further in our next meeting before preparing a proposal for feedback.

We also discussed the related but separate issue of rhythmic feel markings (for swing, shuffle, etc.) and tempo equations or metric modulations. We agreed that in the first instance these would be handled separately from tempo markings, in order to keep our proposal focused on the encoding of tempo text and metronome marks.

We also discussed the issue raised by Robert Patterson concerning beams with only one event (discussion #461). We would prefer that the array of event IDs for a beam should contain a minimum of two events, but unfortunately it is necessary for secondary beams to be able to specify only a single event ID (to encode partial or fractional beams), so we will instead specify a minimum of one event ID for the array in a beam. We also discussed the ambiguity between a beam containing only one note and an unbeamed note with a straight flag, and agreed that in principle we should make it possible to specify the type of flag to be used for a note, including an enumeration for its type (curved, straight angled, straight perpendicular to the stem, etc.) and its direction (whether it points left or right). We will return to this in future.

Next meeting

The next co-chairs meeting is scheduled for Tuesday 2 December 2025.

Co-chairs meeting minutes – October 16, 2025

MNX

Adrian has merged the branch for multi-note tremolo support (issue #119), after adding the things that we discussed in our previous meeting, including the changes to the visual notehead, the number of marks, and so on. Adrian also updated the Sequencing content document to specify how this should work for tremolos. He hasn’t yet implemented styling for tremolos (where the beams/marks are positioned relative to stems), as we still need a way of specifying global styles and overrides, but we have created issue #455 to cover this work so that we don’t lose track of it.

We spent the rest of the meeting continuing to discuss a proposal for the encoding of formatted text. We have now got the bones of a proposal that is fit for community feedback, so Adrian will write up an issue with what we have so far and invite suggestions. We discussed whether there was a suitable existing notation into which we could fold the new formatted text encoding in order to make it more concrete, but everything we considered (tempo, lyrics, dynamics, footnotes) introduced too many other encoding considerations that would distract from the core proposal about the text itself. So we will present the formatted text proposal in the abstract for the time being.

Next meeting

The next co-chairs meeting is scheduled for Thursday 30 October 2025.

Co-chairs’ meeting minutes – October 9, 2025

MNX

Adrian has reviewed the four original “infrastructure” pages in the MNX specification, which were holdovers from the original version of the specification written by former co-chair Joe Berkovitz. Two of them have been removed, leaving two: Notational concepts, which provides some clear definitions of terminology that we use; and Sequence content, which defines how a sequence is structured. These pages are linked to from where appropriate, e.g. where the terminology is used. These pages have been revised to bring them up to date with the current state of the specification: the previous versions were sufficiently old that they were still based on the former XML-based format.

Adrian has also been working on the proposal for multi-note tremolos, and has prepared pull request #454 for these changes, including an example document. We discussed the proposal a little, and agreed a couple of changes, including ensuring that the duration for the note events within the content object should define the displayed notehead duration, rather than their real duration, defining an enumeration to describe the way the tremolo beams join the stems of the notes, and so on. The pull request will be updated with the required changes.

We spent the remainder of the meeting discussing a proposal for how to encode rich text. After some lively discussion around the initial proposal we sketched in our in-person workshop in July, we agreed to resume discussions in our next meeting.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 16 October 2025.

Co-chairs’ meeting minutes – October 2, 2025

MNX

All dictionary objects in MNX can now have a _c object (comment), which can be a string. Adrian has added some comments to a few of the examples by means of demonstration (e.g. here).

Adrian has also added the _x object (extension) to every object for vendor-specific extensions, and as the first example of its use, the MNX documentation now uses the _x object to define areas that can be highlighted in examples to draw attention to particular parts of the encoding.

The documentation now also lists the globally-available attributes in a special section at the bottom of each object page, rather than listing them as if they were specific to that object, which you can see e.g. here.

Adrian has also changed the word “keys” to “attributes” throughout the documentation as this seems to fit better with our use of the word “object”.

Adrian discovered via Reddit a new GitHub project from Oliver Paddock called Capo-Compose that defines a new text-based language for describing music notation that compiles to MNX.

Up next, Adrian plans to complete the encoding of multi-note tremolos, which the co-chairs discussed in the London workshop back in July (issue #119).

MusicXML

The attachment of directions to grace notes was discussed (#602) and it was confirmed that the documentation is correct.

Next meeting

The next co-chair’s meeting is scheduled for Thursday 9 October 2025.

Co-chairs’ meeting minutes – August 28, 2025

MNX

Adrian has added support for attributes common to all objects to the doc generator, which allows us to define id on all objects. For the time being, these common attributes also have common requirements across all objects; in the future, if needed, we may make it possible to override or opt out of specific common attributes, but we will try to avoid this. At the moment, id is listed alphabetically among all the other attributes for an object, but Adrian plans to list them separately to make clear which attributes are unique and which are shared.

Next, Adrian plans to add support for a comment attribute, _c, which will also be common to all objects (issue #428). This will be straightforward to add. Beyond that, we are considering the extension object, _x, which is a little more sophisticated, as it will hold a dictionary of arbitrary objects (issue #429). Adrian hopes to then use this new mechanism to implement highlighting and linking to specific objects in the doc generator.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 11 September 2025.

Co-chairs’ meeting minutes – August 15, 2025

MNX

Adrian has renamed the keys in the interval object to halfSteps and staffDistance as agreed, including updating the other places in the specification where it is mentioned and the examples. He’s also added a note to the documentation for the interval documents about the possibility of adding future types of intervals in future. We will close issue #436.

We discussed issue #435 about how to handle instruments such as trumpets and horns that are written without key signatures in some types of scores and parts. Daniel has outlined a simple proposal in the issue.

We spent some time revisiting the issue of keyFifthsFlipAt (discussion #431), and agreed to take up Myke’s suggestion to change the meaning of this such that it should be interpreted relative to the transposed pitch of the instrument rather than the sounding pitch of the piece. We will work on an improved specification for this property that includes the procedure for correctly applying this value as part of the calculation of the transposed key signature.

On the subject of comments (issue #428), it should be possible to add the key _c to any object. The value can only be a string of arbitrary length; we want to discourage the use of comments to store richer data. Adrian will need to adjust the doc generation tool and the schema to allow this. Adrian will also take the opportunity to add the proposed id key to any object, since the changes required will be similar. If this all goes well, Adrian will then proceed to look at adding the _x key for other extended data.

Next meeting

The next co-chairs meeting is scheduled for Thursday 28 August 2025.

Co-chairs’ meeting minutes – July 31, 2025

MNX

We have addressed the following issues:

• #440: Adrian has removed smuflFont from events, in line with the change made to remove smuflFont from notes
• #438: Adrian renamed the new soundID key name to simply sound, for consistency with other similar places in the specification
• #441: Adrian added some additional fields to kitNote: id, class, and perform.

Myke fixed a problem in the doc generator that was resulting in Windows newline characters unexpectedly appearing in the HTML output.

We discussed #436, which raises the issue of how to represent more than two spellings for a note, given the and came to the consensus view that if you require more than two spellings for a note, for the time being, our recommendation will be to encode the whole part separately, and use layouts to exclude any alternative transpositions from the score and part instantiations as needed.

We also discussed #432, concerning the naming and use of the interval object, and decided that we would change the names of both keys of the interval object: instead of diatonic, we propose staffDistance, and instead of chromatic, we propose halfSteps. Using staffDistance instead of diatonic makes a value of zero clearer, i.e. it doesn’t move the note by any staff positions; and if we’re not going to use diatonic, we should likewise not use chromatic.

Next meeting

The next meeting is scheduled for Thursday 14 August 2025.

Co-chairs’ MNX workshop – July 4, 2025

On Friday 4 July 2025, the three co-chairs were able to meet in London and spent the whole day working together in person on the MNX specification.

Instrument transposition

We started the day discussing issue #287, concerning the handling of instrument transpositions and their effect on key signatures and note pitches when rendering scores in transposed pitch. Instrument transposition is defined at the level of the part object using a new interval type that defines the number of diatonic and chromatic steps required. We did give due consideration to the proposal to define transpositions in terms of the number of fifths and octaves, but ultimately decided that it did not give us significant advantages, though we are leaving our options open for enhancing the interval type to handle other ways of defining intervals in future.

For key signatures, we decided to define a new keyFifthsFlipAt value, also specified in the part’s instrument transposition, that specifies the number of fifths in the key object (i.e. defining how many flats or sharps appear) before the key signature should be “flipped”, i.e. from sharps to flats (by subtracting 12 fifths) or from flats to sharps (by adding 12 fifths).

For notes themselves, we have defined a new written object, which for now contains a single new value, diatonicDelta, expressing the number of diatonic steps that should be added or subtracted from the calculated pitch after considering the part transposition and any required enharmonic flip of the key signature to determine the final written pitch.

Adrian will provide some new example documents that show these new aspects of the specification in action soon. The basic changes to the specification are already live.

Single-line staves

As a precursor to discussing how to encode untuned percussion, we first turned our attention to how single-line staves should be encoded. We agreed to replace the current staves object in part with a new object that describes the number and position of the staff lines in a staff. Remember that we use a staff position type to describe the positions of things like clefs: 0 corresponds to the middle line of a five-line staff, 2 to the line above, 4 to the top line, -2 to the line below the middle line, and -4 to the bottom line. So staves will now be an array of stave objects. A stave object will by default represent a five-line staff (i.e. five staff lines, with positions -4, -2, 0, 2, 4). To encode a single-line staff, you would create a stave object with a single staff line, normally with position 0.

The changes to the specification for these changes will be made soon.

Percussion

To encode unpitched or untuned percussion, we settled upon adding a new parallel object to event that can be used instead of note. kitNote will represent a note on a percussion kit. A percussion kit may be either a standard drum set or another collection of percussion instruments, for example a set of orchestral percussion instruments. The kit definition itself will live in the part, and will specify the instruments in the kit in terms of their staff position on a five-line staff, notehead, and markings (articulations, etc.). kitNote specifies the kitComponent used for that note, which determines the staff position, notehead, markings, etc. by looking up the component in the kit.

The initial changes for unpitched percussion have already been committed to the spec, with more details and examples to follow soon.

Multi-note tremolos

We decided that multi-note tremolos should be encoded in a similar fashion to tuplets. Tuplets are encoded in sequences as a nested content object, allowing events to be encoded with inner and outer ratios specifying the relationship between the notated and effective durations. Multi-note tremolos are normally notated using durations twice as long as their effective duration, representing an inner ratio of 2:1, so we will encode tremolos using their written durations in their own nested content object. Adrian will write up the changes for the specification in due course.

Rich text

At the end of the day, we briefly discussed a proposal for the encoding of rich text. We propose a formattedText object, which contains an array of objects that can either represent regular text or music symbols. Each chunk that requires different formatting will be encoded in its own object, and each object is appended one after the other without any additional whitespace (so whitespace at changes of formatting will need to be encoded in each chunk of text). For regular text, the optional style object will allow us to specify font family, style, size, and other similar properties. For music text, the content will be represented by an array of SMuFL glyph names. It will be possible to encode line breaks using \n in the content strings.

Some more details remain to be worked out, but we will produce a formal proposal for this scheme in due course.

Next meeting

After a very productive day working together, our next meeting will be in two weeks, on Thursday 17 July 2025.