Skip to toolbar

Community & Business Groups

Music Notation Community Group

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/smufl
Group'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.

Final reports / licensing info

Date Name Commitments
MusicXML 4.0 Licensing commitments
SMuFL 1.4 Licensing commitments
SMuFL 1.3 Licensing commitments
MusicXML Version 3.1 Licensing commitments

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Co-chair meeting minutes: September 26, 2024

MNX

Adrian has created an initial pull request (#355) to propose the beginnings of an encoding for lyrics (issue #354).

We spent the bulk of the meeting discussing some aspects of the existing approach, resulting in the decision to change the name of the continues object to hyphen to make it clearer, and agreeing that rather than handling gaps in lines of lyrics using a kind of “sparse array” approach (where a line of lyrics that should not include a lyric for a particular note would need an empty object in an array) we would use an object where lyrics are identified by a string-based key, with the lyric text stored as the value for that key at each position. Adrian will update the pull request to reflect these changes.

We also discussed how extender lines for melismas might be encoded, but did not settle on a specific approach in the course of our discussions.

We welcome further community feedback on the proposal as it stands in the pull request, and expect to merge this pull request ahead of the next co-chairs’ meeting in two weeks.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 10 October 2024.

Co-chair meeting minutes: September 12, 2024

MNX

Adrian has spent some time reviewing the open issues in the MNX project. He has closed 35 issues, the majority of which required no action as they were older issues that are no longer relevant, but there were a couple of issues that necessitated a small change:

  • #258: encode the curvature direction of ties
  • #172: use “double” and “final” instead of “light-light” and “light-heavy” to describe particular barlines

These changes need to be worked through into the MNX converter, which is on Adrian’s to-do list.

Adrian also created a new proposal for how to encode lyrics (#354). There has already been some good discussion on this new issue, and we welcome further discussion from the community. We spent the balance of the meeting discussing the encoding of lyrics, and will in due course add some further thoughts to Adrian’s existing proposal reflecting the discussion.

Doc generator

The doc generator has been moved to its own repository, and Myke and Adrian are now

Next meeting

The next co-chairs’ meeting is in two weeks on Thursday 26 September 2024.

Co-chair meeting minutes: August 29, 2024

MNX

We have decided to migrate the doc generator tool from the MNX GitHub repository to its own repository, which the good people at W3C have created for us. The new repository is found at https://github.com/w3c-cg/mnxdocgenerator, but at the time of the meeting is empty. Adrian is planning to migrate the current version of the doc generator into the new repository, and then register the new location with PyPI so that the doc generator can be installed using the Python package panel pip. Myke will take care of updating the docs on the MusicXML side.

As a next step, Adrian is going to review the open issues in the MNX repository to take stock of where we are, and to identify the next notations whose encoding should be relatively uncontroversial, so that we can fill in more areas of the specification, build examples, update the MNX converter, and the viewer.

Next meeting

The next scheduled meeting will be on Thursday 12 September 2024.

Co-chair meeting minutes: August 15, 2024

MNX

Adrian has renamed the octave-shift object as ottava; in addition to renaming the object, the value describing the number of octaves shifted has now been specified, and the example MNX document has been updated accordingly. This was the last of the object names that needed to be renamed to eliminate kebab case, and as such Adrian has closed issue #344.

The MNX converter has also been updated to handle the updated ottava object.

Adrian has also made some changes to the doc generator tool: issue #351 was raised by Myke and involved renaming some items. In the unlikely event that any community members have a local checkout of the doc generator tool, please note that you will need to regenerate your local database as a result of these changes. The aim of these changes is to make the tool easier to understand for newcomers; there is now only one directory called docgenerator and the directory formerly known as spec is now more aptly named spectools. Myke has also raised issues #349 and #350, which involve some practical issues to improve the experience of working with these tools, and Adrian has been thinking about changes in this area, but further discussion is needed.

We also discussed the possibility of moving the doc generator tool into its own repository to make it easier to work with for the MusicXML specification. Adrian is going to contact the team at W3C to ask them if they can help us set up a new repository for this purpose.

MusicXML

Myke has begun the process of creating a new version of the MusicXML specification for version 4.1, and has moved to the draft CLA for the new version. This work has spurred some of the discussion concerning the doc generator tool, and Adrian’s work will help Myke in the development of the spec.

Myke will continue to develop the workflow for beginning to specify the changes for version 4.1.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 29 August 2024.

Co-chair meeting minutes: August 1, 2024

MNX

Since there has been no further community discussion since our last meeting, we have decided to merge pull request #347, concerning accidental display. Adrian still has the changes required for the octave-shift object (#344) and updating the MNX converter with the most recent specification changes on his to-do list.

MusicXML

We spent a little while discussing issue #529 concerning harmonics. We think that this is a good request, and we will look at this issue in the context of MusicXML 4.1. To ensure backwards compatibility, we will make the number attribute optional for the harmonic element.

SMuFL

We discussed fonts for text-based applications. Daniel is planning as part of the SMuFL 1.5 update to deprecate the existing guidelines for SMuFL fonts for text-based applications in favour of a set of guidelines that prioritises making it possible to type ranges of musical symbols in blocks of regular text at a consistent size, without needing to fiddle with ligatures in order to shift the symbols up or down.

Myke proposed that Daniel should start a draft version of this recommendation, and we discussed a programmatic approach where we could define a data file that specifies ranges of glyphs and the transform and scale operations required to map between the registration and size used in fonts for notation applications and those needed for text-based applications, so that we can have a simple workflow for repeatably converting between the two. Daniel agreed to look into this when time allows.

Next meeting

The next co-chairs’ meeting will be in two weeks on 15 August 2024.

Co-chair meeting minutes: July 19, 2024

MNX

In our last meeting we discussed moving the staff number up from the clef object into the positioned clef object, and Adrian has made that change (git commit). Only a single example document (for grand staff instruments) was affected by this change, and Adrian has updated that too.

We asked for feedback on pull request #347 and we spent a while discussing the responses received on the pull request. We as co-chairs are unanimous that we need the support mechanism not only for accidental display, but also no doubt for other things in future (for example, beaming), and we believe that raising the burden on producers of MNX to have implementations of these algorithms will damage the broader utility of the specification, particularly for applications not solely focused on displaying music notation. Nevertheless, we welcome further feedback from the community before we proceed with this change.

We received an automated security advisory from GitHub’s “dependabot” concerning a known vulnerability in Django, which is used by our doc generator system, and Adrian has merged the resulting pull request.

Myke raised the issue that we still have a single object type with a hyphen, octave-shift, which represents an octave line, which means we cannot yet close issue #344. In deciding how to address this, we decided that we would rename the object ottava (to allow us to use the idea of “octave shift” more generically, for example for the amount of transposition suggested by a clef). We also decided that we would change the value for the amount of shift to be an integer representing the number of octaves. Adrian will make these changes soon, so that we can close off this issue.

Next meeting

The next co-chairs’ meeting will be on Thursday 1 August 2024.

Co-chair meeting minutes: July 4, 2024

MNX

Adrian has added an example MNX document for grand staff instruments, illustrating three key aspects: the part object has a staves object to specify the number of staves, each sequence needs to specify which staff it belongs to, and each clef likewise needs to specify its staff. No specification changes were required to accommodate this example. We discussed briefly whether it makes sense to move the staff from inside clef up to the positionedClef object, where the rhythmic position lives, and agreed that we should.

Adrian has also created a pull request for the support element, which in the first instance is intended to specify whether the document encodes the visibility of accidentals (pull request #347). The field useAccidentalDisplay defaults to false, i.e. by default it is assumed that the consuming application is expected to use its own algorithmic approach to determining where accidentals should appear. If the document does not have useAccidentalDisplay set to true, but then nevertheless specifies accidentalDisplay for one or more notes, we have specified that will be invalid MNX; we are not yet sure whether we can make the JSON schema complain about this issue, but we will look into it. We welcome community feedback on this pull request before we merge it.

MusicXML

Adrian has made the corresponding change to the doc generator for MusicXML to encode long strings as arrays to improve the readability of the diffs (pull request #526).

Next meeting

The next co-chairs’ meeting is scheduled for Friday 19 July 2024.

Co-chair meeting minutes: June 21, 2024

MNX

Adrian has documented that staves are numbered using a 1-based system (git commit).

Adrian has made a change to the specification to remove the micro-syntax for measure location, which was used in six different places in the spec. He has introduced a new object measure rhythmic position that defines the rhythmic position within a particular bar. The git commit message specifies the various places where these changes have been made. The specification and examples have also been updated accordingly.

Adrian is next going to work on a pull request for the supports object for accidental visibility (see minutes of previous meeting), and will follow up with examples that show how things are encoded with reference to a specific staff (discussion #343).

We talked for a while about rich text encoding (with reference to issue #280) and discussed how this might look now that we’ve moved to JSON. Daniel agreed to write up an issue capturing some of the discussion as a starting point for further feedback.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 4 July 2024.

Co-chair meeting minutes: May 30, 2024

MNX

In our last meeting we discussed changes to cautionary accidentals in order to focus on encoding their appearance rather than their semantics, and Adrian has now implemented this via a new enumeration in accidental-display, allowing us to encode that an accidental should be parenthesised or bracketed (commit). There will be more work to do in this area in future concerning encoding the reason for the accidental’s appearance, but we will return to that in future.

We also discussed the need to specify whether a MNX document encodes the display of accidentals, and Adrian plans to move on to this next, preparing a pull request for an initial implementation of a new supports object, which will form the beginning of a general-purpose way of describing the approach to encoding.

Adrian has also made a few improvements to the doc generator tool, including ensuring that Windows newline characters are removed (issue #338), and changing the way the raw JSON file that holds the metadata for the format such that it uses a list of strings, removing new lines from the file and making it easier to read diffs (issue #340). Adrian will make the corresponding change for the MusicXML repository as well.

Adrian also fixed some remaining kebab case values to change them to camel case for the barline-type object (issue #342). A similar change needs to be made for the octave-shift values for octave lines (issue #344), which Adrian will do in due course.

Discussion #343 raises an issue concerning how we encode the staff on which a clef should appear for a multi-staff part, and indeed how in general sequences, events, and notes are assigned to staves. We already have a staff index for parts and sequences, but we will need to add this to both events and notes in order to provide full flexibility in encoding voices, chords, and individual notes that can be assigned to another staff. Adrian will prepare a proposal for this, with some worked examples for multi-staff instruments.

MusicXML

Werner Lemberg has opened discussion #518 concerning the encoding of enclosures in directions. Myke proposes that we specify that sibling directions within the same element with the same enclosure type should share a single enclosure, unless a new putative enclosure-break attribute is set; this attribute would be of yes/no type and default to no. Ideally, we would specify enclosure on the higher-level direction element if it is intended that all of the child elements should be enclosed, but because the current default usage of enclosure on the first child element of direction-type assumes that the enclosure will be inherited by each subsequent child, this feels like too big a change. We welcome further community discussion in discussion #519.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 20 June 2024.

Co-chair meeting minutes: May 16, 2024

MNX

Following on from our last meeting, Adrian has resolved the existing cases where enumerations had the duplicate value none. The affected enumerations were staffSymbol (where none has been replaced with noSymbol), tupletDisplaySetting (noNumber) and barlineType (noBarline).

Paul Overell identified a small error in one of the example projects (issue #336), which Adrian has also fixed.

Werner Lemberg has raised concerns about the line endings in the Git repository (issue #338). Adrian hasn’t yet looked at this issue, but thinks it should be not too problematic.

Werner also raised an issue about the use of the terminology for accidentals, and in particular the use of the term cautionary, which is considered ambiguous (issue #331). In accidentalDisplay, we will remove cautionary and editorial and add a new value enclosure to specify whether and how the accidental is bracketed.

At the moment, MNX specifies that accidentalDisplay must be present if an accidental should be rendered. After some discussion, we have decided that we should relax this restriction, since we are concerned that this might be difficult for every class of applications (since it implies that they should have implemented an algorithm for determining where and whether accidentals should be displayed). We propose adding a supports dictionary to MNX, similar to (but more structured than) the identically named element in MusicXML, to allow the exporting application specify its approach towards encoding accidentals (and, in future, other notations). Adrian will create a pull request for this in due course.

MusicXML

There has been some lively discussion concerning our proposal to move the DTD doctype identifier to a domain that is under the direct control of the CG (discussion #503). We welcome further feedback from the community on this issue. Myke suggested the one possibility would be to try changing the doctype identifier during the development phase of MusicXML 4.1 to uncover any problems, with a commitment to review the decision before the end of the development period.

Adrian also fixed a problem with the Python requirements.txt for the doc generator tool that needed to be pinned to a specific version of Django so that Myke could get it running on his own system in preparation for a MusicXML revision.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 30 May 2024.