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.
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.
We’ve started to feel that a good chunk of the “bones” of MNX are becoming reasonably stable — so Adrian has put together an initial version of a live MNX viewer:
This tool lets you enter raw MNX code and view a graphical rendering of the music. To our knowledge, this is the first-ever software that renders MNX JSON — an exciting milestone!
At the moment, it’s limited to very basic music, as the primary goal was to establish the underlying web infrastructure for the tool. Adrian plans to continue working on the viewer to add support for more of MNX.
The purpose of the tool is twofold. First, we hope it helps developers get to know MNX by experimenting and interacting with it. Second, it provides an opportunity to “eat our own dogfood” by writing code that parses MNX, to get a practical sense of the developer experience. Adrian has reported it was reasonably easy to build this and identified a few small ways we could improve our documentation to make it smoother.
It’s important to note this viewer is built on the (closed-source) Soundslice technology, for no other reason than pragmatism: it’s what Adrian knows from his day job. It was much faster to do that than to learn another notation rendering library. We’d be delighted if somebody in the community wanted to lead an effort to build an MNX viewer using completely open-source software. Please get in touch if you would be interested in this.
Community member Yuriy Kravets raised a handful of issues which Adrian has been looking at. Issue #327 was closed without taking action. In #328, Yuriy proposed that the denominator for time signatures should be allowed to use units of 16 and 32, so Adrian has tightened up the encoding of time signature denominators to use an enumeration. In #326, Yuriy pointed out that the type attribute for barlines was not required, and Adrian has tightened this up too.
Next meeting
The next co-chairs’ meeting will be in two weeks on Thursday 25 April.
Adrian has improved the doc generator system to handle enumerations (issue #321), and the automatically generated JSON schema now also includes this information, so that all the allowable values for string-based types are specified.
There were a couple of JSON objects that didn’t have enumerations defined, so Adrian has added them where it was simple to do so. A couple of issues remain where the intent is to use the values from MusicXML, but Adrian hasn’t yet gone ahead and brought those values over; this will be done soon.
Myke suggested that we should probably prefer lower camel case rather than using hyphens to separate multi-word enum values, as this maps more cleanly onto the default enum types in languages like Javascript and Python. Adrian agreed that this would be a good change.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 11 April 2024.
Adrian has merged the pull request #322 for event markings: MNX now supports 11 types of markings in the event object. Adrian has added support to the MNX converter for importing these markings from MusicXML.
In issue #323, Myke suggested that we should disambiguate the use of the term position, which was currently being used both for rhythmic position and for vertical position within the staff. We now use staff-position for vertical positiion. Adrian has also implemented support for this in the MNX converter.
Adrian also found an old issue #256 to rename tied to tie, which has now been updated in the specification, examples, and in the MNX converter.
Next, Adrian is planning to tackle issue #321, to improve the generation of the JSON schema to include all of the possible values for enumerations in the schema.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 21 March 2024.
Adrian has created a pull request (#322) to address issue #103 with a proposal for the encoding of 11 different markings, including all the MusicXML articulations (with the exception of the markings that should be note-specific, namely the jazz articulations like scoop and fall) and single-note tremolos. We decided to go ahead and merge this pull request since there has been no dissent from the community on the proposal as described in the original issue.
As a next step, Adrian will implement support for these new markings in the MNX converter.
We also briefly discussed Myke’s issue #323 about the reuse of the word position to refer to both rhythmic position and vertical position within the staff, and we propose using staffPosition for position with the staff, to disambiguate the two dimensions.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 7 March 2024.
Adrian has been continuing to think about how to encode articulations (issue #103). In order to side-step the issue of determining once and for all what constitutes an articulation, which could be a controversial issue, he is proposing that we use a less semantic, more general way of grouping notations that apply to all the notes in a chord, i.e. in MNX terms at the event level.
After some further discussion, we have settled on the idea of having an object called markings within event that defines a set of markings that can be added to the event; for example, staccato, tenuto, accent, marcato, and so on. These will be objects in their own right, but can typically be empty unless they need to define any specific additional information such as placement, symbol overrides, etc.
Having arrived at a consensus among the co-chairs, Adrian will now prepare a pull request with a proposal for community feedback.
Next meeting
The next co-chairs’ meeting will be on Tuesday 22 February 2024.
Adrian has prepared a proposal for the encoding of articulations (issue #103). We discussed the pros and cons of storing articulations directly within the event or within a dictionary or list, and this became a wide-ranging discussion about how similar sorts of note- or event-specific notations – including ornaments, instrument-specific techniques, etc. – could be encoded. There is certainly a lot of detail for us and the community to get our teeth into.
The concrete outcome of this discussion was that we agreed it would make sense to encode the articulations within a structure (either a list or dictionary) in the event, rather than encoding each one in the top level of the event, because it seems clear that there will be many more items that need to be encoded at this level, and we want to avoid having too many top-level keys at the event level.
Community feedback on the proposal for articulations is welcomed.
Next meeting
The next co-chairs meeting will take place on Thursday 8 February.
Adrian has merged pull request #319 regarding the automatic JSON schema. Myke suggested changing the indentation to two spaces, which Adrian has also done. Adrian is working on a further refinement to include the allowed enumeration values for data types in the JSON schema (issue #321), but this requires some additional work on the doc generator tool, so this is ongoing.
We have closed issue #308 from Paul Overell for the creation of the JSON schema, with grateful thanks to Paul for all his work on this issue.
Adrian has also made a pass through the JSON key names and has made the use of the term “staff” consistent; previously we had a mixture of “stave” and “staff”. We will standardise on “staff” singular and “staves” plural, as this matches common usage.
We also briefly discussed implementing articulations (issue #103), and Adrian will work on a proposal that uses the same basic types as MusicXML for community review as soon as possible.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 25 January.
Adrian was planning to merge the pull request for the automatic generation of the JSON schema (pull request #319), but Paul Overell suggested a further enhancement for enriching the data types for integers and enumerations, which Adrian is in the process of implementing.
We discussed whether it would be a good idea to merge what has already been done and then follow up with a smaller change set for the delta, and Adrian agreed that he would do this.
Next co-chairs’ meeting
The next co-chairs’ meeting will be on Thursday 11 January 2024. The co-chairs wish everybody in the community group a happy and restful holiday period and look forward to further valuable collaboration on the development of our projects next year.
Adrian has also modified the docs generator system to create a JSON schema automatically (pull request #319) from the specification. Adrian is grateful to Paul Overell (@paul-bayleaf) for the work he has done on manually creating and updating a JSON schema file to MNX up to this point – his work has made it much quicker to check that the resulting automatically generated JSON schema is complete and correct. So many thanks to Paul!
Adrian would welcome feedback from community members (especially Paul) on the correctness and completeness of the JSON schema. He plans to merge these changes within a week or so, unless there are any problems found in community testing.
Adrian has also added support for grace notes to the MNX converter, along with a new test in its test suite.
For unpitched notes (issue #316), which we discsussed in our last meeting, Adrian has added a new issue for percussion mapping more generally (issue #320). As a group, we agreed that we will park both of these issues for now: we don’t think it makes sense to handle unpitched notes without percussion mapping, and the latter is a big area in its own right. We welcome community feedback on percussion mapping, in terms of use cases, examples, considerations, so that we have more information ready for when we return to this area.
Adrian proposes as the next order of business that he address a number of small and uncontroversial changes in service of making it possible to generate MNX files using the MNX converter that are more complete for so-called “simple” music – though exactly what constitutes simple music is of course up for grabs.
Next meeting
The final co-chairs’ meeting of the year will be in the week of 18 December, date to be confirmed.
Adrian has created the necessary staff position data type for position on staff, and has updated clefs to use this new staff position data type, and similarly updated both the MNX converter and all of the MNX examples (issue #315).
The next steps are to consider how to encode the staff positions of unpitched notes (issue #316), and how to position the staff positions of rests (issue #318). We agreed that in normal single-voice sequences, rest staff positions do not need to be encoded, and we will provide tables (possibly both in the speicifcation and in structured data) providing the nominal positions of rests, based on the origin points of the rest glyphs in the SMuFL specification: for example, a half rest (minim) would have position 0, and a whole rest (semibreve) would have position 2. We agreed that for multiple voices in the same measure, it would be advisable to encode the position of every rest.
Adrian also plans to add support for grace notes to the MNX converter in the near future.
MusicXML
We agreed that we will incorporate the proposed extensions to MusicXML sound IDs for marching percussion proposed by Zac Jansheski (issue #494) in the MusicXML 4.1 release.
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 7 December.
w3c/musicxml
