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.
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.
Adrian has made the changes for issues #313 and #314 for the encoding of positions within a bar and clef positions. Changes have been made to both the MNX specification and the MNX examples.
Adrian has also been working on the MNX converter. He’s updated the converter to handle the change in how sequences are encoded in the new top-level sequences object. Clefs, including inner-bar clef changes, are also now handled in the MNX converter, along with a new test case for clefs in MusicXML. Adrian has also improved the error handling in the MNX converter, showing a descriptive error message rather than the Python traceback. Based on a suggestion from Mogens Lundholm (issue #3), errors for invalid elements in MusicXML file now show the line number of the invalid entry. Next, Adrian plans to implement grace notes in the MNX converter (issue #7).
We discussed how to encode unpitched notes (issue #316), and came to the consensus that we should encode unpitched material using staff position rather than relative to a specific clef. Adrian will work this up into a formal proposal shortly.
Finally, and further to our last meeting, we discussed the community feedback on the numbering of staff positions (issue #315), and agreed that we will proceed as described. We decided that we would assume that when we come to describe the distances between staff lines, we would limit them to integral values as multiples of this staff position unit (which can be thought of as half a space, or half a standard notehead’s height).
Next meeting
The next co-chairs’ meeting will be on Thursday 24 November 2023.
We briefly discussed the proposal in issue #494 from @zacjansheski to extend the list of sound IDs to more specifically encode the sound quality of marching percussion instruments, and agreed that this would be a good change.
MNX
Following our discussion in our last meeting about issue #314 for a unified way of encoding rhythmic position, there has been no feedback from the community dissenting against this change, so in the interest of keeping moving forwards, Adrian will write up the required specification change to implement this, and then update the MNX Converter to handle clef changes in the light of this improvement.
Next, Adrian plans to run a bunch of MusicXML files through the MNX Converter to identify which kinds of notations are not yet at all handled and set our next priorities.
Adrian also plans to start looking at the automatic generation of a JSON Schema from the docs generator and specification, and will use the example schema developed by Paul Overell in pull request #308 as the basis to check that the generated schema matches well enough.
We briefly discussed issue #294 concerning the JSON representation of rests, and in particular how the vertical position of the rest should be encoded. We have decided to proceed with the encoding of rests as described in this issue, so will close that issue, and have opened issue #315 to discuss the approach towards encoding the vertical position of non-pitched items on staves, including rests and clefs (which will require some rework in the light of this change).
Next meeting
The next co-chairs’ meeting is scheduled for Thursday 9 November.
Following on from our last meeting discussing ways of defining fully-qualified positions for items in bars, Adrian has created issue #314 and we welcome community feedback on how we might approach this. Since Myke was back this week, we spent much of the meeting discussing this issue in more detail, and by the end of the meeting had settled on an enhanced version of the original proposal, to add information about the voice to which the grace note index applies. Adrian has added this as a comment to the issue.
Myke also plans to start looking at some of the (hopefully) less controversial MusicXML encodings for items like chord symbols, figured bass, Roman numeral harmony analysis, direction, and technical, and to start considering how some of these might be easily ported across to MNX and expressed in JSON rather than in XML.
Next meeting
The next co-chairs’ meeting will be on Tuesday 24 October 2023.
Myke was unfortunately unable to join today’s meeting due to illness.
MNX
The pull request for moving clefs into their own key in the measure object (#312) has been merged, but in the process of working on this it became clear that we needed to reconsider how we encode the position of clefs within the bar (#313). We spent the bulk of the meeting discussing different possible approaches, and the two leading contenders are to add an extra dimension to the way the position is defined in order to fully qualify it relative to grace notes, either using a rhythmic offset or using an index into the list of grace notes at that position. Adrian will write up these two approaches and their pros and cons as we understand them in the issue, and we look forward to further community feedback.
Adrian plans to update the MNX converter to convert clefs following the completion of the initial work on moving clefs.
Next meeting
The next co-chairs’ meeting is scheduled for Tuesday 12 October.
Adrian has updated the MNX converter to output the new JSON format (GitHub commit). There are a few remaining details that need to be resolved (clefs, repeat endings, and tuplets) but these will be taken care of in due course. It’s not yet ready for prime time, so community members should hold off on testing the converter for the time being.
In the course of working on this, it emerged that the current design for the encoding of clefs is a little awkward. Clefs are currently encoded in the part measure object inside the content key, intermingled with sequences (that hold notes and rests). After some discussion, we agreed that it made sense to simplify part measure by moving clefs into a top-level key at the same level as beams, allowing us to remove the content key and have beams, clefs, and sequences at the same level within part measure.
Next up, Adrian will focus on implementing more of the MNX specification in the MNX converter, as this will likely flush out a few more awkward design issues like the clefs issue we discussed today.
Adrian also plans to look at the pull request (#308) contributed by Paul Overell to provide a JSON schema for MNX, and will figure out the next steps for how to integrate this schema into the project.
Next meeting
The next co-chairs’ meeting will be on Tuesday 28 September 2023.
We had some excellent bug reports on the MNX example documents from community member Paul Overell in issue #306, and Adrian has worked through them to fix them all. Thanks to Paul for this very detailed look at the examples.
Adrian has also completed the work discussed at our last meeting for accidentals in issue #288 and both the specification and examples have been updated.
We briefly discussed a couple of the remaining issues that have arisen from the transition from XML to JSON. We decided to close issue #298 concerning start and end repeat barlines, and issue #296 concerning the encoding of global measures, with no further action.
Next up, Adrian is going to update the MNX converter project to output JSON. The test suite for the MNX converter also needs to be updated to reflect the recent changes to remove micro syntaxes, but we think it’s reasonably certain that the subset of the syntax in these tests is now more or less set in stone. So once this is updated to output JSON, this should provide a stable foundation for future development.
MusicXML
Myke has decided that issue #492 concerning the way MusicXML encodes different short/tick barlines should be handled in MusicXML. In due course we will decide how the differences should be encoded: possibilities include extending the bar-style enumeration with new values, or specifying how the vertical extent of the barline should be specified relative to the staff lines on a five-line staff.
Next meeting
The next co-chairs’ meeting will be in two weeks on Thursday 14 September.
w3c/musicxml
