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.
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.
The co-chairs wish everybody in the Community Group a happy New Year!
MNX
Over the past couple of meetings we have been discussing how to encourage some initial implementations of the parts of MNX that we consider stable and unlikely to change significantly as we continue to flesh out the remaining parts of the specification.
With this in mind, we are working on a reasonably detailed list of the types of notation that MNX will likely ultimately support. This will allow us both to produce a roadmap towards our eventual 1.0 release, but also to identify the parts of the specification that are stable enough to implement now.
We plan to open the list for community contributions in due course, but we believe we have made a solid start. The next step will be for Adrian to turn the list into a simple, single-page web app that will allow us to slice and dice the list by category and item.
Next meeting
The next co-chairs meeting is scheduled for Thursday 16 January 2025.
Adrian has merged the pull request for lyric line global metadata (#359).
We spent some more time discussing the issue of how to map out the remaining areas of the specification that still need to be written, and which parts of the specification we can consider safe for implementation in their current state. We will have more to share in the New Year.
MusicXML
There are two interesting areas of discussion that Myke wants to bring to the attention of the community:
Firstly, issue #565 discusses how support for MIDI 2.0 could be added to a future version of MusicXML in a backwards-compatible way.
Secondly, a report of inconsistencies in one of the sample documents hosted on musicxml.com, which are still the property of MakeMusic rather than of the CG, has broadened into a discussion about what kinds of sample documents we might want to develop in future. Please visit issue #568 to read more.
We welcome feedback from the community about these issues.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 2 January 2025.
Adrian has fixed the issues raised by Paul Overell in issue #358. One of the fixes involved changing the JSON schema to handle the identifier to be used for the lines property of the lyrics object. Adrian took the opportunity to make it possible to run JSON schema validation against all of the MNX example documents as well, as described here.
Adrian has also created pull request #359 to handle metadata for lyrics in the global object. It provides a dictionary using the lyric line identifiers as the key, a label used for reference, and the language that the lyrics are in. In future, this can be expanded to include additional information like style information. We welcome community feedback on this pull request.
We discussed some of the remaining work for lyrics, including how to encode which lines of lyrics are active in different regions of the score, and talked about the idea of “zones” as a data type to describe regions of bars, which could also become useful for encoding other types of data.
We also continued to discuss how to bring the MNX specification to a stable version 1.0, and to survey the parts of the specification that have already been completed with a view to how confident we feel that implementers would not be at risk of having to significantly rework things that they implement. We like the idea of producing a comprehensive list of notations encoded by MNX, in order both to map out comprehensively those areas yet to be specified, and also so that in the future applications can clearly document which aspects of the specification they import, export, preserve, etc.
The co-chairs will begin work on building this comprehensive list, and then open it up to the community for contribution.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 5 December 2024.
Pull request #355, which adds basic support for lyrics, has been merged, closing issue #354. As discussed in the previous co-chair meeting, the type of lyric is encoded with an enumeration, and the “lyric line” object has been renamed to “event lyric line” to make its purpose clearer.
Next, we’re going to tackle the top-level structure for the document that defines the lines of lyrics that are used in the document (which will probably be called “lyric line”, now that we have freed up this term). This needs to include metadata like a unique ID, order, language, placement, and possibly other things, though probably not style/presentation data.
Vale: Don Byrd
The co-chairs are sad to learn of the passing of Donald “Don” Byrd, who died aged 78 this past Tuesday, 22 October after a short illness. Don has played an important part in the development of music notation software, standards, and representations. His early music printing program SMUT was used to produce the music examples for Douglas Hofstadter’s 1979 book Gödel, Escher, Bach: An Eternal Golden Braid, and in the 1980s, he developed Nightingale for the Apple Macintosh. He was involved in the development of the NIFF format in the 1990s, and has done invaluable work in the field of Optical Music Recognition.
Next meeting
The next co-chair meeting is scheduled for Tuesday 5 November 2024.
Adrian has updated pull request #355, which is the proposal for how lyrics should be encoded. The change to use a dedicated user-defined key for the lyrics object was more involved, because it required changes to the doc generator tool as well in order to generate the specification and the JSON schema.
Having decided in the last co-chairs’ meeting that we would rename the originally proposed continue object to hyphen, after discussing the issue of Korean text raised by Samuel Bradshaw, we have decided to switch to an enumeration called type with values whole, start, middle, and end, defaulting to whole.
We also discussed renaming lyricLine, which is currently used to identify the individual row of lyrics belonging to an event: we want to use lyricLine to identify the whole line of lyrics, and propose that the existing lyricLine should be renamed eventLyricLine, making clear that it belongs to the lyrics local to that event.
We spent a bit of time discussing some of the notations that are often represented using lyrics in existing music notation software (for example, percussion sticking, harmonic analysis, figured bass, or even chant notation) and how these should be encoded in MNX. We had the idea of creating a kind of “kitchen sink” for rows of note-attached text to accommodate these kinds of use cases in the (short- to medium-term) absence of dedicated MNX encodings for these features. We would be interested to hear from the community about this issue, so Adrian will create a discussion on GitHub for feedback.
After we have completed this initial step of encoding lyrics, we’ll move on to lyric metadata, for example, whether a line of lyrics represents verse, chorus, translation, etc. Adrian will prepare a proposal for this after this pull request has been merged.
Next meeting
The next co-chairs’ meeting will be on Thursday 24 October 2024.
w3c/smufl
