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.
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.
Adrian has made the changes we discussed in the last meeting that the event type object is optional. This has been removed from all of the example documents, and in our estimation this feels much better, and cuts down significantly on bloat.
In relation to discussion #402, Adrian has made the change that sideEnd no longer has an implied default value; it’s now up to the application to decide.
Per discussion #418, Robert Patterson has released a version of his denigma tool for handling Finale MUSX files.
Related to discussion #420, Adrian plans to extract the MNX example documents from the document generator tool and add them as separate files in the repository so that they can be accessed simply by cloning the MNX repository.
Adrian has also updated the MNX viewer to validate against the JSON schema, and will show validation errors. There is still much more to do on which notations are supported by the MNX viewer, but having proper validation is a good step forwards.
We also discused the ongoing conversation around the encoding of beams (issues #399 and #419, among others), and we will provide some further thoughts in response to this issue in due course.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 8 May 2025.
The slur object no longer has a location key. Adrian deleted an example that contained an incomplete slur since it should be reworked into a laissez vibrer tie example in future. The target object is now required for slurs. We have also defined some initial values for line type, which is used by slurs. Together, this addresses discussion #402.
Octave lines are now encoded in an array, like clefs, rather than being embedded in the sequence. The example document has been updated. It is also now possible to specify that the octave line applied only to a single voice, by specifying the voice ID. This closes issue #413. We also elected to specify that octave lines can shift by 1, 2, or 3 octaves; previously this was limited to 2 octaves up or down.
Adrian also made corresponding changes for dynamics, so they are also now stored in an array in the part measure object instead of being embedded in the sequence. This closes issue #408. Adrian has added an example document for dynamics to illustrate this change.
sequence now contains only a handful of object types, which feels good. We agreed that type should be made optional for objects in sequence, defaulting to event, so that we do not need to redundantly encode the type for events, which make up the vast majority of objects in sequences. We also discussed issue #391, and agreed that a new sequence content object should be exposed to provide a common way of describing the content of sequence and tuplet.
Adrian has also changed the duration key within the space object to use a fractional rather than integral value, which makes it more expressive and allows it to specify any valid musical duration. This addresses issue #400.
We talked for a while about grace index, sparked by a discussion about how to differentiate between an octave line that ends before the grace notes before a primary note versus how to include the primary note and all its grace notes. We are leaning towards making the implicit default value of grace index null, which would replace the current default value of undefined.
Next meeting
The next co-chairs meeting is scheduled for Thursday 24 April 2025.
Further to our discussions in the previous meeting, Adrian has made the changes to the specification for accidentalDisplay per discussion #366. The linked comment provides links to the relevant specification changes.
We discussed Robert Patterson’s proposal to move ottava to part.measure (issue #413) and we found ourselves in broad agreement. We think ottava should move from sequence to part.measure and provide an array of octave lines, specifying the direction and number of octaves shifted, the optional voice to which it applies, and the start and end positions, specified using measure rhythmic position (which specifies both the measure, and the rhythmic position within the measure, including the index into any run of grace notes at that position).
In the process of looking at this, we discovered that slurs do not use measure rhythmic position, but Adrian will review the way that slurs are positioned, and remove the location object altogether, since our expectation is that this will prove redundant once the start and end position is specified more fully.
We also discussed issue #412, and ended up coming to the consensus that dynamic should also move from sequence to part.measure, so that dynamics apply to all sequences by default. Like octave lines, they can target a specific voice, and also specify an optional staff to determine where they appear.
With regard to discussion #410, after some discussion, we resolved that we would retain the existing event.markings structure as currently specified, on the grounds that it’s important that the markings themselves can be objects with additional information about their appearance, placement, and so on.
Next meeting
The next co-chairs meeting is scheduled for Thursday 10 April 2025.
Adrian has committed the changes to encoding of ties as discussed in the last co-chairs’ meeting, per issue #396, which is now closed.
Related to discussion #366, we revisited the need for useAccidentalDisplay. Because we propose to add the force key on the accidentalDisplay object, which would capture the semantics of whether the accidental was automatic or explicitly specified, there’s an argument that useAccidentalDisplay becomes redundant.
In Adrian’s mind, the original idea behind useAccidentalDisplay was to differentiate between “the absence of data” means “null” versus “false”: it provides a shorthand to avoid having to encode information on every single note.
The most compelling case we could think of was the difficulty in distinguishing between an MNX document saved from, say, a MIDI sequencer that doesn’t write out accidentals and an MNX document that simply doesn’t require any displayed accidentals because all of the music is unaltered relative to its key signature. For pure renderers (e.g. Vexflow) that do not have the capability to calculate accidentals, the one advantage of having an explicit useAccidentalDisplay object is that it would allow them to display some kind of warning that the pitches may not be displayed.
Myke will add comments to the relevant discussions based on our discussions in this meeting.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 27 March 2025.
Adrian provided some rapid-fire updates on a number of issues recently raised by members of the community group:
The specification has been updated to state that it uses the language codes defined in RFC 5646, the successor to the older ISO 639 standard (issue #363)
For tempo markings, location was defined as a measure rhythmic position, but given the tempo is already in a measure, this is redundant, so only a rhythmic position is required (issue #373)
Some of the JSON keys were using bar and some were using measure; everything is now consistently called measure throughout (issue #375)
Robert Patterson suggested (in discussion #385) that the docs should show the parent relationship for each object, which has now been implemented
The definition of staff in sequence was incorrect, and this has been corrected (issue #387)
Adrian has also improved the spacing around object descriptions in the documentation.
The bulk of the meeting concerned issue #395, the encoding of ties.
Ties are encoded on the starting note: for a tie between notes, target specifies the ID of the note where the tie ends; for a hanging tie, we use the key location, which specifies the rhythmic position at which the tie ends. We also provide for a means of specifying an indeterminate starting and ending position for a hanging tie in or out of a note.
Before we moved to JSON, for hanging ties we used a microsyntax to describe the rhythmic position at which the tie ended, or special values for inbound and outbound with no positions specified. However, we have eliminated microsyntaxes from MNX, so this no longer fits with the design of the format.
Issue #396 contains Adrian’s proposals for how to improve the encoding of ties. After some discussion, we arrived at the consensus that we should simplify ties such that note.tie becomes note.ties, which is a list of tie objects (containing a target specifying either a note ID or that it is a laissez vibrer tie). We propose that we will not encode so-called incoming ties: we believe these are either presentational in nature (as in engravings where ties are shown in separate halves, but which are semantically still single ties) or are concerned with repeat jumps (in which case they are semantically handled by being specified in targets).
Adrian will update issue #396 with an updated proposal, and we welcome further input from the community.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 13 March 2025.
Robert Patterson reported that two of the MNX documents in our set of examples didn’t pass JSON Schema validation, so Adrian has fixed those, such that all example documents now validate.
Robert also raised two issues concerning system layout (issue #367) and the placement of system objects (issue #368) which need further thought. We agreed that we would digest these issues and respond directly in GitHub.
In Issue #363 Adrian Kulisch suggests that we should explicitly use the language codes defined in RFC 5646, which updates the earlier ISO 639 standard. We agreed that this would be a good change for MNX and indeed for MusicXML 4.1.
We also discussed issue #366 concerning the accidental display object, as raised by Robert. We propose that to address the concerns here we will add an optional force bool to the accidental display object, which will allow the encoder to specify whether the accidental is explicitly shown or explicitly hidden. We will wait for community feedback before we add this to the specification.
Work continues on the list of notation types that we are creating in order to identify the areas of MNX where the specification is ready for implementation. Adrian has created a prototype single-page web app that as discussed in our previous meeting, and we agreed that he should continue working on this in the coming weeks. We will share it with the community once it is a little further along.
Next meeting
The next co-chairs’ meeting will be on Thursday 13 February 2025.
w3c/smufl
