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.
– 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.
Daniel has (finally) been working on improving the tooling for working on the SMuFL specification to remove the reliance on the internal Django-based tool, so that it is easy for contributors to work on changes to the specification themselves.
The SMuFL specification itself and the SMuFL metadata files are now automatically generated and published using a GitHub workflow, built from a set of YAML files that encode the glyph ranges, including recommended and optional glyphs and their relationships.
As part of this work, the sources for Bravura, the SMuFL reference font, have also now been added to the SMuFL repository in UFO (Unified Font Object) format, and the automated pipeline also generates both OTF and WOFF versions of the font, and its JSON metadata file, as part of the publication workflow.
This means it is now possible to add a new range of glyphs, or a new glyph to an existing range, by editing the YAML files, and run an automated pipeline to update the spec, metadata files, and the Bravura UFO source, where appropriate empty glyphs will be added. Of course, it is still necessary for a maintainer to design and implement the new glyphs in the Bravura font, but this process ensures that the specification, metadata, Bravura font, and Bravura font metadata move in lockstep.
Daniel has also made two new Bravura releases using this new pipeline, the second of which implementing a lot of feedback that has been piling up over the last few years.
Contributors are very welcome (indeed encouraged) to tackle any of the issues currently assigned to the SMuFL 1.5 milestone in the issue list. A full guide for contributors can be found here, and feedback on this document is likewise welcome.
MusicXML
Karim hasn’t had a chance to send his regular progress update to the mailing list at the time of the meeting, but will do so in the next day or so.
The current focus is working on the roadmap, focusing on a single issue at a time, ensuring that the complete checklist of steps required to successfully make a specification change is being followed, and Karim is refining that checklist as he goes. One refinement, for example, is to ensure that notationref is updated for each change.
Other issues that are planned for the release are also still under discussion with the community as work continues towards getting those issues ready for implementation on the roadmap.
Karim’s plan for the MusicXML test suite is to sync them with the LilyPond MusicXML test suite from which they are drawn, since the LilyPond suite is being updated more quickly than ours.
New formats.music domain
We have registered a new domain formats.music that we intend to be the canonical homes of the formats developed by the CG, and if there is interest from the developers and maintainers of other music formats, we would be very happy to provide subdomain-level redirects for those formats. For now, you can use mnx.formats.music, and smufl.formats.music to reach the GitHub pages sites for these two of the CG’s formats. MusicXML will follow as soon as possible.
Next meeting
The next co-chairs’ meeting is scheduled for Monday 24 August 2026.
We were very pleased to receive a pull request from new contributor, Owen Williams, who identified a problem with the storage of the dynamic constants.
Measure repeats
The work on encoding measure repeats (issue #520) has been incorporated into the spec, including some new example documents (here and here).
Pointing
We discussed at some length the issue around the pointing object in strong accent (issue #525), and we believe that this is directionally correct. We think that making it possible to define an arbitrary glyph is not really right: it’s not really helpful to be able to define, say, a clef glyph to appear for a marcato. We propose that we should address this on a per-object basis, and use an appropriate term for each object, rather than trying to force everything to fit this single term.
We are also considering whether the term orient to describe whether an item is placed above or below the staff should be changed: upon reflection it feels as if placement (as used in MusicXML) would be clearer.
Next meeting
The next working group meeting is scheduled for Tuesday 11 August 2026.
The updated documentation site is up, and as of the last few days now also has search functionality.
Work is continuing on the test infrastructure. Every commit now goes through a set of test that are meant to validate the schema’s syntax, and tests for the examples included in the documentation. Schematron infrastructure is now also in place, and work is proceeding on coming up with trapping issues that are syntactically valid but semantically incorrect. Karim eventually hopes to document how developers of implementations of MusicXML can use these tests to validate that their application’s export is semantically correct.
Myke Cuthbert has also contributed his fork of the MusicXML test suite to the CG, and that repository has now been moved to the w3c-cg organisation.
In addition to this important infrastructure work, Karim has started working on the roadmap for MusicXML 4.1. He’s made a checklist of everything that would need to go into a pull request for a schema modification: this needs to include not only the schema modification, but also documentation, examples, and so on. Now that he has the process, he’s following it and refining it as he goes. Two or three items have already made it onto the roadmap and he is working on more. This Version History page will be maintained with the changes as they arise.
Karim is also encouraged by the detailed discussions on specific notations, including for improving the representation of ties and slurs. Karim also plans to send a regular update to the public mailing list with progress on specific issues.
notationref
Karim has merged in the current state of support for MusicXML to notationref. Our plan is to move the canonical location for the MusicXML and MNX JSON files to their individual repositories.
Next meeting
The next co-chairs’ meeting is scheduled for Monday 10 August 2026.
Myke was unable to attend this meeting due to travel commitments, so only Adrian and Daniel were in attendance for this session.
Dynamics
We agreed to expand the number of dynamic levels from ppp<->fff to pppppp<->ffffff, to match MusicXML and the range of glyphs provided in SMuFL (#521)
For accent-dynamic, we agreed that we would use the same dynamic levels as an immediate dynamic, with two enumerations for prefix and suffix, allowing you to specify a prefix of s, r or nothingand a suffix of z or nothing. (#521)
We agreed that we would add an optional ID – for now called visuallyContinues – that specifies a previous dynamic that should be considered as linked for the purposes of alignment (#521)
We revisited how we handle fp dynamics and propose that we remove attackValue and instead encode them as accent-dynamics, with a new residualValue value to specify that the dynamic level continues as p (#522)
To accommodate a gradual dynamic that ends on a different staff, we will add endStaff to dynamic group, using the staff number (#523)
Measure repeats
We haven’t had any community feedback on the proposal for measure repeats (#520), so Adrian plans to go ahead and add this to the spec as-is.
Next meeting
The next MNX specification working group meeting is scheduled for Tuesday 28 July 2026.
w3c/smufl
