Co-chair meeting minutes: January 27, 2026

Forthcoming Community Group meeting

Everybody in the Community Group is invited to attend a virtual meeting on Tuesday 17 March 2026 at 4pm UTC (5pm CET, 11am EST, 8am PST). This meeting will give the first opportunity to hear from our new MusicXML specification editor, Karim Ratib, and updates on the MNX and SMuFL projects.

We will share the Zoom link for the meeting in due course. In the meantime, please save the date!

Changes to co-chair meetings

Following Karim’s appointment, the co-chairs have decided to modify our cadence of meetings. We will continue to meet every two weeks, rotating through three meetings: two meetings will be focused on MNX, with the third being more broadly about updates from the spec editors of all three active projects (MNX, MusicXML, and SMuFL).

MNX

Adrian has implemented group barline styles (issue #471), as discussed in the previous co-chair meeting, and has updated relevant example documents to make use of this new functionality.

Adrian has also created a branch with a new approach for full measure rests (issue #475). The new approach introduces a fullMeasure attribute on sequence. Events no longer have a measure attribute, which means that duration for events is now always required, which is a good improvement, and also allows a simplification in the parsing of sequence content. A new example document has also been created to demonstrate these changes. Further community feedback is welcomed before this is adopted into the specification.

Next meeting

The next meeting will be an MNX working group meeting, on Tuesday 10 February 2026.

Co-chair meeting minutes: January 12, 2026

MNX

For applications that need hints for the encoding of ties across repeat endings or other non-contiguous notes (issue #476), we have now added a targetType attribute to the tie object.

For encoding whole measure/bar rests (issue #475) we propose adding a fullMeasure attribute on the sequence object, which can contain a representation object, which can contain a rest object (and perhaps in future objects of another type, for example to allow you to specify that it should be blank rather than showing a rest).

We also discussed Adrian’s proposal for how to encode barline grouping across multiple staves (issue #471), and decided that we would expand the proposal such that the default should be for barlines to join all staves belonging to the same instrument. We discussed how to handle edge cases like organs (where typically the staves for manuals are joined by a single barline, and the staff for the pedal has its own independent barline) and whether this would require explicit encoding.

Next meeting

The next co-chairs meeting is scheduled for Tuesday 27 January 2026.

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.