Co-chair meeting minutes: March 10, 2026

Community Group meeting

A reminder that we will have a virtual meeting next Tuesday, 17 March 2026 at 4pm UTC to which all Community Group members are invited. This meeting is a chance for the co-chairs to provide an update on each of the CG’s specifications – SMuFL, MusicXML, and MNX – and for the new MusicXML specification editor and co-chair, Karim Ratib, to introduce himself to the community.

MNX

Adrian has completed the specification for which characters are allowed in IDs (issue #503): up to 256 ASCII characters, and no spaces or non-printable characters can be used. This ID system is designed to make it possible to use the internal IDs used by other applications (for example, MuseScore) in MNX documents.

We spent a bit of time discussing the default file extension for MNX documents, and whether we would need an OCF-style container for MNX, per discussion #416. Our current thinking is that we probably do not need a container, so we propose that MNX documents should have the file extension .mnx.json. Consuming applications can check the file extension, that the document parses as JSON successfully, and that it has a top-level mnx key.

Next meeting

The next meeting is the Community Group virtual meeting on Tuesday 17 March 2026. The next co-chairs’ meeting is scheduled for Tuesday 24 March 2026.

Co-chair meeting minutes: February 24, 2026

SMuFL

Karim has some ideas for changing the metadata and tools for working with them, so Daniel encouraged him to open issues for those things

MNX

The schema now has an official version number, and the version number is incremented with each revision; it started at 1 and is now at 4 already; issue #497 is thus addressed.

There has been some good discussion about measure indexes, measure numbers, and how you point at measures from other places within an MNX document (issue #447). The indexing part has now been nicely addressed: we previously used a 1-based index for referring to bar numbers. We discussed changing it to being 0-based, but instead we decided to use the measure ID. Multi-measure rests, the measure rhythmic position object, and system (part of the layout infrastructure) now all use IDs.

One remaining thing for measure numbers is the label (issue #501). There has been a spirited discussion about how to encode the label. We don’t yet have a really clear definition of what we’re trying to achieve: it could be more than simple numbers. A couple of suggestions have been made for how this should be encoded. Myke proposes that this is good enough for now, and that we punt issues concerning bar numbering for Broadway and other similar niche cases for the future, or encourage that community to make a proposal that we can include later on.

The next issue to consider is what constitutes a valid ID. We don’t currently provide any info beyond that it should be a string. Our original idea was a simple alphanumeric value, but Robert Patterson pointed out that it would be nice to save MuseScore’s internal ID, which contains other characters. Adrian will make a proposal for issue #503 for this. We briefly discussed whether the string should use only printable ASCII characters, and agreed this is probably sufficient.

Next meeting

The next co-chairs’ meeting is scheduled for Tuesday 10 March 2026.

Co-chair meeting minutes: February 10, 2026

Co-chairs

A point of clarity: following the appointment of Karim Ratib as the new MusicXML specification editor, he is also now co-chair of the Community Group, joining Adrian and Daniel. Myke is no longer co-chair, but remains closely involved in the development of MNX. The Community Group web site, GitHub repositories and wiki will all be updated in due course to reflect this.

MusicXML

Adrian, Daniel, and Myke congratulated Karim on the excellent start he has made as spec editor, including making contact with other experts in the community and making some initial decisions about long-standing issues. Karim is also working on a presentation about his vision for the future of MusicXML and how it compares to MNX, which he will share at the forthcoming Community Group meeting in March.

MNX

Adrian has merged the pull request for the encoding of full measure rests, so issue #475 is now closed. Adrian has also made some small documentation changes to close issues #480 and #481.

Per discussion #494, community member Robert Patterson has implemented MNX import and export for MuseScore, and his pull request has been accepted by the MuseScore developers. This has raised the importance of versioning of the specification, so that it is easier to identify the level of support in applications like MuseScore, per issue #497.

After some discussion, we propose that we will use a URL for the version of the form https://w3c.github.io/mnx/docs/mnx-schema.json/version/123 that doesn’t resolve to a valid URL. We propose that while MNX is in heavy development we will simply increment the integer at the end of this URL, and then consider jumping to, say, 1000 for the first stable release.

We discussed issue #447, and agreed that we should remove index from global-measure, since it is no longer needed.

Next meeting

The next co-chairs’ meeting is scheduled for Tuesday 24 February 2026.

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.