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 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.
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.
w3c/smufl
