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.
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.
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.
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.
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.
Adrian has renamed the keys in the interval object to halfSteps and staffDistance as agreed, including updating the other places in the specification where it is mentioned and the examples. He’s also added a note to the documentation for the interval documents about the possibility of adding future types of intervals in future. We will close issue #436.
We discussed issue #435 about how to handle instruments such as trumpets and horns that are written without key signatures in some types of scores and parts. Daniel has outlined a simple proposal in the issue.
We spent some time revisiting the issue of keyFifthsFlipAt (discussion #431), and agreed to take up Myke’s suggestion to change the meaning of this such that it should be interpreted relative to the transposed pitch of the instrument rather than the sounding pitch of the piece. We will work on an improved specification for this property that includes the procedure for correctly applying this value as part of the calculation of the transposed key signature.
On the subject of comments (issue #428), it should be possible to add the key _c to any object. The value can only be a string of arbitrary length; we want to discourage the use of comments to store richer data. Adrian will need to adjust the doc generation tool and the schema to allow this. Adrian will also take the opportunity to add the proposed id key to any object, since the changes required will be similar. If this all goes well, Adrian will then proceed to look at adding the _x key for other extended data.
Next meeting
The next co-chairs meeting is scheduled for Thursday 28 August 2025.
#440: Adrian has removed smuflFont from events, in line with the change made to remove smuflFont from notes
#438: Adrian renamed the new soundID key name to simply sound, for consistency with other similar places in the specification
#441: Adrian added some additional fields to kitNote: id, class, and perform.
Myke fixed a problem in the doc generator that was resulting in Windows newline characters unexpectedly appearing in the HTML output.
We discussed #436, which raises the issue of how to represent more than two spellings for a note, given the and came to the consensus view that if you require more than two spellings for a note, for the time being, our recommendation will be to encode the whole part separately, and use layouts to exclude any alternative transpositions from the score and part instantiations as needed.
We also discussed #432, concerning the naming and use of the interval object, and decided that we would change the names of both keys of the interval object: instead of diatonic, we propose staffDistance, and instead of chromatic, we propose halfSteps. Using staffDistance instead of diatonic makes a value of zero clearer, i.e. it doesn’t move the note by any staff positions; and if we’re not going to use diatonic, we should likewise not use chromatic.
Next meeting
The next meeting is scheduled for Thursday 14 August 2025.
On Friday 4 July 2025, the three co-chairs were able to meet in London and spent the whole day working together in person on the MNX specification.
From left to right: Myke Cuthbert, Daniel Spreadbury, Adrian Holovaty
Instrument transposition
We started the day discussing issue #287, concerning the handling of instrument transpositions and their effect on key signatures and note pitches when rendering scores in transposed pitch. Instrument transposition is defined at the level of the part object using a new interval type that defines the number of diatonic and chromatic steps required. We did give due consideration to the proposal to define transpositions in terms of the number of fifths and octaves, but ultimately decided that it did not give us significant advantages, though we are leaving our options open for enhancing the interval type to handle other ways of defining intervals in future.
For key signatures, we decided to define a new keyFifthsFlipAt value, also specified in the part’s instrument transposition, that specifies the number of fifths in the key object (i.e. defining how many flats or sharps appear) before the key signature should be “flipped”, i.e. from sharps to flats (by subtracting 12 fifths) or from flats to sharps (by adding 12 fifths).
For notes themselves, we have defined a new written object, which for now contains a single new value, diatonicDelta, expressing the number of diatonic steps that should be added or subtracted from the calculated pitch after considering the part transposition and any required enharmonic flip of the key signature to determine the final written pitch.
Adrian will provide some new example documents that show these new aspects of the specification in action soon. The basic changes to the specification are already live.
Single-line staves
As a precursor to discussing how to encode untuned percussion, we first turned our attention to how single-line staves should be encoded. We agreed to replace the current staves object in part with a new object that describes the number and position of the staff lines in a staff. Remember that we use a staff position type to describe the positions of things like clefs: 0 corresponds to the middle line of a five-line staff, 2 to the line above, 4 to the top line, -2 to the line below the middle line, and -4 to the bottom line. So staves will now be an array of stave objects. A stave object will by default represent a five-line staff (i.e. five staff lines, with positions -4, -2, 0, 2, 4). To encode a single-line staff, you would create a stave object with a single staff line, normally with position 0.
The changes to the specification for these changes will be made soon.
Percussion
To encode unpitched or untuned percussion, we settled upon adding a new parallel object to event that can be used instead of note. kitNote will represent a note on a percussion kit. A percussion kit may be either a standard drum set or another collection of percussion instruments, for example a set of orchestral percussion instruments. The kit definition itself will live in the part, and will specify the instruments in the kit in terms of their staff position on a five-line staff, notehead, and markings (articulations, etc.). kitNote specifies the kitComponent used for that note, which determines the staff position, notehead, markings, etc. by looking up the component in the kit.
The initial changes for unpitched percussion have already been committed to the spec, with more details and examples to follow soon.
Multi-note tremolos
We decided that multi-note tremolos should be encoded in a similar fashion to tuplets. Tuplets are encoded in sequences as a nested content object, allowing events to be encoded with inner and outer ratios specifying the relationship between the notated and effective durations. Multi-note tremolos are normally notated using durations twice as long as their effective duration, representing an inner ratio of 2:1, so we will encode tremolos using their written durations in their own nested content object. Adrian will write up the changes for the specification in due course.
Rich text
At the end of the day, we briefly discussed a proposal for the encoding of rich text. We propose a formattedText object, which contains an array of objects that can either represent regular text or music symbols. Each chunk that requires different formatting will be encoded in its own object, and each object is appended one after the other without any additional whitespace (so whitespace at changes of formatting will need to be encoded in each chunk of text). For regular text, the optional style object will allow us to specify font family, style, size, and other similar properties. For music text, the content will be represented by an array of SMuFL glyph names. It will be possible to encode line breaks using \n in the content strings.
Some more details remain to be worked out, but we will produce a formal proposal for this scheme in due course.
Next meeting
After a very productive day working together, our next meeting will be in two weeks, on Thursday 17 July 2025.
Adrian has added the showOctave boolean to the clef object, and updated the description for the glyph value in clef to make clear that if your only reason for specifying the glyph is to specify that the clef should show an octave indicator, you should use showOctave instead. This closes issue #424.
Adrian has also added a supports.usesBeams boolean: if this is set true, it is assumed that every beam is encoded, and that if no beam object is specified, no beam should be shown.
Finally, Adrian has also committed the big changes for the encoding of beams, making the encoding of secondary beams optional (so they are implied if they are not encoded), handling the encoding of partial beams or hooks. Adrian decided to leave the encoding of secondary beams as they are in existing examples, and create a new example that shows the two approaches for secondary beams. After further consideration of the recent comments on issue #419, Adrian decided to retain the list of explicit events in the beam, on the basis that it assumes too much implicit knowledge, e.g. that grace note events should be excluded. Adrian will make some further revisions to the new example for secondary beams to make it clearer, and then plans to close issue #419.
Next, Adrian will add support for beams to the MNX converter (which currently has no support for beams at all).
The three co-chairs will be meeting in person to spend the day working on MNX in London in two weeks, so between now and then Adrian will finalise the list of items to be discussed in the workshop. We are hoping to make some significant progress on a few items when we are able to work together in person for a whole day.
Myke outlined a brief proposal for vendor-specific extensions to MNX. He proposes that we should allow a key called _x for arbitrary structured data and a string called _c for comments in every MNX object. Applications will be free to ignore, consume, preserve or discard this data as they wish. Myke will raise an issue with some further details for feedback.
Next meeting
The next co-chairs’ meeting will be an all-day workshop on Friday 4 July 2025 in London.
Paul Overell raised issue #424 concerning the encoding of an octave clef in one of the examples. This raised some interesting issues about the encoding of octaves. We decided that we should use the same ottava amount object used in octave lines, and we will add a show-octave boolean defaulting true to determine whether the octave indicator should be shown. To specify an actual clef glyph, which can almost always be inferred from the combination of clef staff position and octave amount, there’s a glyph value that can specify a SMuFL symbol.
Regarding beams (issue #419) we spent a bit more time discussing the issue of partial beams or hooks. We agreed that we should encode them in the same way as beams, but with the same starting and ending note, and an optional direction object, with possible values of auto, left, or right, defaulting to auto. We also agreed that we should make primary beams required if the application encodes beams, and that secondary beams can be derived. We propose that we will also add some information to time signatures to define metrical structures that will make it easier to derive, and that in due course we will also add a “supports beams” feature that would also allow applications to specify that they do not encode beams at all. Adrian will write up these further changes in due course.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 19 June 2025.
To start the meeting, we had a brief discussion about whether we could or should try to formalise the criteria for whether a set of symbols can be considered for inclusion in SMuFL, since we have had a number of recent proposals that have presented difficulties in assessing whether they are in sufficiently common use.
Myke proposed that we use the following criteria: a symbol can be encoded in SMuFL if it has been used in at least two works by different composers and published by different, independent publishers. We welcome community feedback on this proposal.
MNX
After we made the MNX example documents more accessible in the filesystem, @paulbayleaf found a couple of errors which he reported in #422 and #423, which Adrian has now fixed.
Adrian has added a means of encoding common time and cut common time signatures, which closes issue #94. He has also added an example document that exercises these changes.
Adrian has also brought the MNX converter up to date with a number of the most recent changes to MNX, including to ties, accidentals, slurs, and so on. There are still further things on Adrian’s wish list that he plans to work on.
On the continuing topic of beams, Adrian has closed issues #299 and #399, leaving issue #419 open. (We spent the whole of our last meeting on 8 May discussing beams without arriving at any firm conclusions, which is why there were no minutes from that meeting.)
After a great deal of discussion, we believe we have hit upon a scheme for encoding beams that is both less verbose than the original proposal, but still completely explicit for every beam line. We will encode each visible beam line, specifying the first and last note in that beam (with the rule that grace notes encountered in the sequence are ignored). The beam object will itself be nestable, so beam lines after the primary beam will be encoded in a dictionary within the primary beam.
Adrian will write up our proposal and publish it in #419 for community feedback. The co-chairs all feel good about this proposal, and it has come after a great deal of consideration, so we hope it will meet with community approval!
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 5 June 2025.
w3c/smufl
