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.
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.
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.
Adrian has added the work to date on dynamics to the specification. After further discussion in the meeting today, we have settled on a system that provides four dynamic types: immediate, gradual, relative, accent.
For the case of fp dynamics, there’s an “attackValue” (allowing a distinction between attack value and persisted value) for immediate dynamics.
To specify the end of a hairpin, there’s an “end”, matching how ottavas are encoded (as opposed to the original idea of giving the hairpin a duration).
There’s a “glyphs” array, allowing the encoding of a specific series of SMuFL glyphs, for cases where the enum of dynamic values doesn’t include what should be visually rendered.
Instead of rich text (which would by definition require the redundancy of encoding the dynamic value twice), there’s a “prefix” and “suffix”, both of which are strings.
There’s a “relative” type, for dynamics such as “più p” (meaning “quieter”).
We’ve also decided to add “n” (niente) to the dynamic value enum.
Measure repeats
Adrian has created issue #520 with a proposal for measure repeats, based on the discussion in our previous meeting. We welcome community feedback on this proposal.
Beat repeats
We spent the remainder of the meeting discussing potential approaches for beat repeats, or slashes. A couple of promising approaches presented themselves, but we will discuss further in our next meeting and then formulate a proposal.
Next meeting
The next MNX specification working group meeting is scheduled for Tuesday 30 June 2026.
Following some feedback from Robert Patterson on our proposal for how to encode dynamics, we agreed that we would change gradual dynamics to express their extent using measure position instead of duration. This is both consistent with how octave lines are encoded.
We also decided that gradual dynamics should have no end value, because this can create an ambiguity in the event that you have multiple abutting gradual dynamics. We will instead only define the starting dynamic, and if you need to define the end dynamic, you will add an immediate dynamic at the gradual dynamic’s end position.
We also decided that we would not need to encode messa di voce in a special way: a crescendo-diminuendo swell can be encoded as a pair of abutting gradual dynamics.
Adrian will tighten up these final details and then add the current proposal to the specification.
Measure repeats
We made good progress on an initial design for measure repeats, sometimes known as ditto or simile marks. We propose that each measure will have an optional measure repeat object, which will be set for the first measure that shows the measure repeat; for a one-measure repeat, each successive bar will have this set; for a two-measure repeat, the first bar will have this set, and the second bar will not, and so on. Each measure repeat will specify the number of measures to be repeated, an optional count (to show that this is the nth repeat in a sequence of measure repeats), and an optional number of slashes in the measure repeat symbol.
Adrian will prepare a formal proposal for this in due course and share it for community feedback.
In our next meeting we will discuss beat repeats, or slashes.
Next meeting
The next specification working group meeting will is scheduled for Tuesday 16 June 2026.
Adrian has put together a proposal for the encoding of dynamics (issue #518) which is now ready for community feedback. However, we quickly got involved in discussing the text object, and how it didn’t feel quite right that in common cases (such as “sempre f“) it would be necessary to effectively encode the value of the dynamic (f) twice, once in the value field and then again using a SMuFL glyph in the text field.
We propose that instead we should have prefix and suffix fields that contain a plain string that can be drawn to either side of the dynamic value. In this way, text only needs to be specified for very unusual cases.
We also talked at length about modifiers, and ended up with a proposal of the values for an enumeration that can go alongside value (containing, among others, “more”, “less”, “immediately”, “as much as possible”, etc.).
This led us to consider dynamics that express an immediate relative change, such as “a little louder” or “much softer”, and so we propose that we will add a new relative dynamic type.
Adrian will extend the issue with formal proposals for these aspects, and we look forward to reading feedback from the community about them.
Measure and beat repeats
We had planned to discuss bar/measure and beat repeats (issue #122) but ran out of time. We will consider this in our next meeting. If any members of the community would like to bring any specific concerns in this area to our attention, we invite you to add details to issue #122 ahead of our next meeting.
Next meeting
The specification working group will next meet on Tuesday 2 June 2026.
Daniel, Adrian and Karim were unable to meet, but Karim has provided the following MusicXML update.
MusicXML
The new MusicXML docs site (issue #644) is fully functional and pending some cosmetic fixes before we can deploy it live. We’ve received some feedback already and encourage more users to review it. One specific area where we could use more eyeballs is the changes made to the xsd schema files to move the documentation from the site back into the specific elements/attributes/types:
Milestone 4.1 has been revived and the set of tagged issues is more or less final. I believe I have a good grasp on what needs to be done for each, but I welcome community review of those issues specifically.
Regarding milestones and releases, and given some feedback from Michael Good (@mdgood), I am thinking of targeting multiple minor releases per year, which will include documentation changes and minor edits to the schema such as new enumeration values, new attributes. Deprecations, new elements and other major changes will be kept for major releases once per year or less. I’ve started a Milestone 5.0 to that effect. What’s missing is a “release manual” which lists all the chores needed for a release.
Semantic validation (pull request #627) is stalled and will resume over the summer. The core proof of concept is done (Schematron being the selected technology). A good initial set of validations has been identified, mainly thanks to Werner Lemberg (@lemzwerg). What’s missing is to organize all this in a new “test” area of the repo.
Next meeting
The next co-chairs’ meeting is scheduled for Wednesday 3 June 2026.
Adrian has also updated MNX in notationref to account for these changes.
We spent the majority of the time resuming our discussion about the representation of dynamics, with a particular focus on how gradual dynamics (hairpins, cresc., dim., etc.) should be encoded. After some lively discussion, we arrived at consensus on an approach that Adrian will write up for community discussion in the coming days.
Next meeting
The next MNX specification working group meeting is scheduled for Tuesday 26 May 2026.
w3c/smufl
