The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases.
The Community Group documents, maintains and updates the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle a broader set of use cases and technologies, including use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML and SMuFL specifications.
The group is developing a new specification to embody this broader set of use cases and technologies, under the working title of MNX. The group is proposing the development of an additional new specification to provide a standard, machine-readable source of musical instrument data.
w3c/smuflGroup's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Pull request #556 adds support for caesuras over barlines; we agreed to merge this.
Pull request #554 adds support for slide in and slide out to note markings; we agreed to merge this.
Pull request #558 adds support for lyric extender lines; we agreed to merge this, pending some minor changes from Robert.
Pull request #559 adds support for D.C./D.S. al Coda types; we agreed to merge this.
We also agreed that in order to accelerate the pace of development, we will move towards merging pull requests after a few days provided there has been no strong objection, rather than waiting for the next working group meeting to confirm in person.
Chord symbols
We spent the remainder of the meeting discussing the encoding of chord symbols. The upshot is that Adrian will work on a proposal that primarily draws upon the existing harmony element in MusicXML, and share it for community feedback.
Next meeting
The next working group meeting is scheduled for Tuesday 20 October 2026.
Karim continues to work on roadmap items for MusicXML 4.1. There has been some good feedback for the special interest groups for microtonality and instrument techniques.
Karim is still hoping to get some traction for a special interest group for accessibility, so if there are any community members who have expertise in this area, we would love to hear from you.
Some UI fixes have been made on the MusicXML specification site, to fix some issues with scrolling on mobile devices.
SMuFL
Daniel has not had a chance to devote any time to working on SMuFL in the last fortnight. But the next step remains the same: there are some old pull requests in the SMuFL repository that need to be updated to take advantage of the new tooling. He hopes to get this done before the next meeting.
Next meeting
The next co-chair meeting is set for Tuesday 20 October 2026.
Robert reported that he has been working with Peter Yang on making it possible to translate Finale .musx files into Viritura using MNX, producing a gap report that identifies areas where encoding isn’t yet possible.
Previous business
Following up on the items discussed in our last meeting, Adrian reported:
Percussion clefs are now implemented
A new boolean for hiding clefs has been added
Caesuras are now added to event markings; work remains to add them to global barlines.
Orientation versus placement
We discussed the thorny issue of orientation versus placement. The orientation object will be renamed to placement. The keys for markings – for example, breathmark.orient – will also be renamed from orient to placement.
We also discussed the old concept of cascading placement from events to other markings, and agreed that we will retire this.
In the light of the recent work on voice direction in MusicXML, we also discussed this for sequences in MNX, in order to specify the nominal stem direction of a voice. We settled on the name directionHint, which will use an enum with values upper,lower and auto as the value.
Next meeting
Our next meeting is scheduled for Tuesday 6 October 2026.
Karim has created special categories within the Discussions area on GitHub for each of the new special interest groups, and discussion about specific issues has already started to happen.
A useful new addition has been added to the spec this week thanks to contributions from a lot of people, providing new functionality for describing the default stem directions for voices (pull request #707). During the work on this ticket, Karim learned how to use LilyPond as a renderer for the required examples, and hopes to introduce a common pipeline for the generation of graphical renderings of full MusicXML examples, rather than a pipeline.
MNX and SMuFL
No specific updates to share this week. The next MNX specification working group meeting is tomorrow
Next meeting
The next co-chair meeting is scheduled for Monday 5 October 2026.
– Removed from roadmap: Add ‘smufl’ attribute to <senza-misura> https://github.com/w3c-cg/musicxml/issues/643 (thanks @lemzwerg – as per issue discussion, there’s broader work needed at the level of mixing SMuFL glyphs into textual content.)
While working on roadmap issues, it became clear to me that more often than not, specialized knowledge and focused attention on specific topics would be of great help to push groups of issues forward. I am therefore calling on members of the community to express their interest in forming special interest groups around the following, and other, topics:
Work on specifying the number of staff lines (pull request #548, issue #531) is now complete. It’s now possible to specify zero as the number of staff lines. We agreed that the pull request can be merged. There is further work to be done on how staff configurations interact with layouts, but we’ll return to this in future.
Veritura
In discussion #549, Peter Yang announced the release of a new web-based notation editor called Veritura that uses MNX as its native format. The implementation makes liberal use of the _x vendor extensions mechanism. Adrian asked Peter which of their specific extensions could be taken more or less as-is and used in upstream MNX.
Caesura
We started by discussing caesuras: these could be added to markings relatively simply, in the same way as breath marks. They will need to incorporate the different types of caesuras currently supported by MusicXML. Myke suggests that we should define the shape (“thin”, “thick”, “curved”, etc.) and the number of strokes (an enumeration with values “single” and “double”).
Percussion clefs
We then moved on to discussing percussion clefs: the main issue is how to map the note staff positions. Although the intention is that notes on unpitched percussion instruments should be written using “kit notes”, we can specify that pitched notes written on a percussion instrument will be positioned as if the percussion clef is the same as a G clef. We will add the value “percussion” to the “sign” enumeration used by the clef sign object. We will also add a boolean for “hide”, defaulting false, to allow the hiding of any clef, including the new percussion clef.
Rich text
We revisited last year’s proposal for encoding rich text from issue #459. After much lively discussion, we agreed that the current proposal is more or less fit for purpose, modulo a decision on exactly how to refer to a semantic style ID registered globally in the document. Adrian will make a fresh proposal for how text items can be encoded in measures, with a type enumeration intended to specify the text item’s purpose.
We left as a treat for our next meeting a decision on how to specify the mapping between text size and musical space size.
Next meeting
The next spec working group meeting is scheduled for Tuesday 22 September 2026.
Karim has been working on items from the roadmap. Progress can be slower than expected because of the hidden complexities that tackling even superficially simple-looking issues can reveal, but this is all good and interesting work.
Karim is considering proposing the formation of special interest groups for areas within MusicXML. He has seen this approach working well within the MEI community, and is considering whether this approach could work for MusicXML. He will create a discussion in GitHub to invite proposals from the community for what kinds of special interest groups could work for MusicXML.
MNX
Adrian wanted to mention the announcement of Viritura, a new web-based collaborative music notation editor that uses MNX as its native format. You can read more about it at its web site, or in discussion #549 at GitHub. Of particular interest is that it makes extensive use of the _x vendor extension method to implement support for notations not currently handled by the MNX specification. We will discuss this more in our spec working group meeting tomorrow.
Next meeting
The next co-chair meeting is scheduled for Monday 21 September 2026.
The MNX doc generator tool no longer requires a back-end database or a web site in order to update the documentation. Everything is now driven from scripts, making it much easier to update the docs: pull requests will also be much simpler, as the edits will be more transparent.
Number types
Per issue #546, Adrian has now made it possible for MNX to use integers and floats, instead of all numbers being integers.
Staves and staff lines
Per issue #531, Adrian has preprared pull request #548 with a proposal for how to encode staff lines in the part measure. After some discussion, partmeasure.staves will remain an array, where each element is a position.staffConfigs, where each staffconfig has a staff key, like clefs, so it’s possible to identify which staff it applies to.
We moved on to specify the maximum number of staves in a part, leaving apart issues of temporary extra staves like ossias. For example, a piano part might typically have a maximum number of staves of 2. For a piano part that might need two extra staves at some point in a piece, you would specify the maximum number of staves as 4, but hide the extra staves where they’re not needed.
We discussed the potential ambiguity of describing the distance between staff lines in terms of staffPosition, meaning that the gap between the staff lines in a normal 5-line staff is 2. Myke proposed that we describe the numeric type used by staffPosition and the distance between staves as a new type, diatonicUnit, which represents one diatonic step on the staff, or half a staff space; this type, rather than staffPosition, can then be used to specify the distance between staff lines. More discussion here is needed – we may choose to leave this out for the time being.
Next meeting
The next spec working group meeting is scheduled for Tuesday 8 September 2026.
Robert Patterson joined Adrian, Myke and Daniel for this meeting.
Staff lines
We discussed Adrian’s proposal for how to specify the number of lines in a staff, issue #531. We spent a lot of time discussing whether the information about staves in general really belongs in a part (because this has big consequences for things like doubling instruments, as at the moment both instruments would be encoded in the same part, with the implication that the displayed switch between instruments will occur in the same place in all layouts). We decided to park that concern and instead take as read that wherever the information about staves actually lives, we still need a way to describe the number of staff lines and their separation.
We discussed various use cases that need to be considered, such as the two-line staff often used in Orff Schulwerk scores, staves where a regular five-line staff needs to be augmented with an extra staff line for advanced instrumental techniques, changes in the number of staff lines at different points in the music, and so on.
After much discussion, we have settled upon the idea that staves can be defined in part measures, so there will be a convention that you should define one at the start of the first measure; this will allow changes in staff information from measure to measure. Adrian will update the proposal in the issue, and Myke and Robert will provide some further music examples to help shape the proposal.
Next meeting
The next meeting is scheduled for Tuesday 25 August 2026.
With the build system for the documentation site and the test system now firmly in place, it is possible to achieve good velocity with actual work towards the next MusicXML 4.1 release https://github.com/w3c-cg/musicxml/milestone/3. Here are the items that have moved in the past period:
– Many discussion topics and issues have arisen around clarifying the documentation, removing ambiguity, addressing edge cases for the sake of application developers. Thanks to @lemzwerg, @rpatters1 and others for bringing these issues forward – once I feel they reach a place of clarity and mutual understanding, we can consider adding them to the roadmap.
w3c/smufl
