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.
It was recently announced that Musikmesse 2022, which had been scheduled for 29 April–1 May 2022, has been cancelled, and the B2B part of the fair has been cancelled permanently. The co-chairs are considering some alternative events and conferences that might possibly be a future home for our in-person meetings in Europe:
Open source:FOSDEM, normally in Brussels in February.
W3C:TPAC, which rotates around the world, and in 2022 is expected to be in Vancouver, Canada, and it’s not clear when it will next be in Europe.
We could also consider meeting at IRCAM in Paris, or at Steinberg’s headquarters in Hamburg.
We welcome any further suggestions of events, conferences or organisations that could host our in-person meetings, and feedback on whether any of the above would be preferable.
Adrian has created pull request #282 to cover the proposal for styling attributes in issue #263, and welcomes feedback. Adrian has written a synopsis in the pull request itself as an introduction, and invites the community to digest the pull request and provide further feedback.
Adrian will next turn his attention to developing a proposal for how to handle the differences between full scores and instrumental parts, for issue #34.
Daniel has started some initial work on SMuFL 1.5, with the intention of producing a new revision of the specification by the end of 2022. He has created a SMuFL 1.5 milestone on GitHub and has reviewed all of the existing open issues, assigning 30 of the 48 open issues to that milestone for consideration and potentially implementation. An updated set of labels has also been added, and these labels have been applied to the existing issues.
Daniel has also decided to use mdBook instead of GitBook to produce future versions of the specification, and the current editor’s draft is now using the new mdBook output. mdBook is more lightweight than GitBook, has a better author-test-publish workflow than GitBook, and produces output with a better user experience, including enhanced search.
One of the issues that we hope to address in the next revision is #214, to provide translations for the human-readable names in the glyphnames.json and ranges.json SMuFL metadata files. The co-chairs are currently evaluating a pair of online translation management tools (Transifex and POEditor), both of which provide a free service to open source projects.
We have also enabled the GitHub Discussions area for any questions about how to use SMuFL, announcements about any new software that implements SMuFL support, and so on. Please feel free to make use of this new discussion platform.
If you have any issues that you would like to be considered for inclusion in SMuFL 1.5, please ensure they have been raised on GitHub as soon as possible so that we can start to bring the scope of the new version into focus.
The next co-chairs’ meeting will be on Tuesday 29 March 2022.
We have now implemented the GitHub Discussions feature for the MusicXML repository as agreed at the last co-chair meeting. If you have any questions about MusicXML, or any announcements about products adding support for MusicXML, please make use of the Discussions area on GitHub.
Pull request #281 (for issue #185), for the specification of layouts, has now been merged. Issue #263, concerning the proposal for the infrastructure for styling, is now ready to be formalised into a pull request. After this proposal has been merged into the specification, separate issues to cover the specifics of defining the various styles that can be applied to elements in MNX documents will be added; Adrian proposes adding a single style property to the specification so that there is a fully worked-out example.
Following that work, the next area to be tackled, as previously discussed, will be for dealing with the differences between scores and parts, in particular things like note spelling, as covered by issue #34.
The next co-chairs’ meeting will be on Tuesday 15 March 2022.
We have decided to enable the Discussions feature on GitHub for the MusicXML repository. This is intended to be a place for questions about MusicXML, but not bug reports in the specification or documentation, or proposals for new features: those should still be raised as issues, as before. Several issues that have been raised recently would actually have been better served as discussions, and so we hope that this will prove to be a useful resource for the developer and user community.
Adrian has integrated some further changes in pull request #281 for issue #185, addressing feedback from community members to ensure that the examples and the specification match, and renaming a couple of the elements specified. We anticipate the pull request will be merged within the next few days.
The next area of work is going to be producing some examples in support of issue #263 to bring the proposal for styling towards a pull request. We hope that producing some concrete examples of these new properties in action will help other community members assess the overall proposal and give further feedback.
The next co-chairs’ meeting will be on Tuesday 1 March 2022.
It appears unlikely that we will be able to plan to get together at an in-person event this coming spring. There is still uncertainty over whether events like Musikmesse in Frankfurt and The NAMM Show in Anaheim will occur as currently planned, and it appears that logistically not all of the co-chairs will be able to attend either of these events in any case. Other potential opportunities for an in-person meeting in the spring present similar challenges.
Therefore the co-chairs propose that we will continue to meet online this year. Our last community group meeting was in October, so our current thinking is that we will plan for an online community group meeting in the autumn.
It may be that one or more of the co-chairs is in attendance at either Musikmesse or The NAMM Show, and if so, we will aim to arrange a social gathering for any community group members who are also in attendance.
Pull request #281 has been prepared by Adrian to bring the staff and system layout changes proposed in issue #185 into the specification. Christina Noel has prepared a set of music examples that demonstrate these new features in action, which you can find here. We are currently gathering feedback on the pull request and certainly welcome further feedback from community members who may not have yet had the opportunity to review the changes. The co-chairs request that any further feedback is submitted on the pull request itself by the end of this coming Friday, 4 February 2022.
The updated Group Charter comes into effect today, following the completion of the election on 9 January 2022. The proposed update passed by a margin of 24 votes for to 0 votes against.
The community group wiki will be further updated with a link to the two previous versions of the charter and the election results in due course.
Adrian has been working on pulling together the changes proposed for issue #185. The current status of this work is that there is a new top-level layouts container element. The next step is to develop a series of examples to demonstrate this element, and these will be coming soon.
The next area of work will be to focus on the proposal for style properties described in issue #263. If you would like to get an overview of this proposal, Joe Berkovitz’s comment here provides a synopsis.
Now that the updated Group Charter is in effect, we can begin the formal work on the instrument data project. Daniel will work on an initial list of requirements as a starting point for discussion and share at the next meeting, all being well.
The next co-chair meeting will be on Tuesday 1 February 2022.
If you have not yet cast your vote for or against the charter update, please go to the Charter Election page on the group wiki to do so. Once you are at the election page:
If you don’t see any Edit options, log in to your W3C account by clicking Log in in the upper right corner of the page. You created a W3C account when joining the Music Notation Community Group.
Click on the “edit” link in the appropriate Votes section to add your Yes or No vote. Please put your name on a separate line in the bulleted list.
If you find you cannot log into your W3C account or have other problems editing the wiki page to cast your vote, you may also cast your vote on the public-music-notation-contrib mailing list. One of the co-chairs will then transfer your vote to the wiki election page.
Adrian has updated the mnxconverter and its test cases to use the new element names that were decided upon for #265.
Adrian also plans to publish a pull request addressing the proposals for grouping parts described in issue #185 for discussion and approval. If any members want to read a summary of the proposal ahead of the pull request’s publication, they can read this comment from Christina Noel on the issue.
The next co-chairs’ meeting will take place on Tuesday 18 January 2022.
After the publication of the draft of the revised Community Group Charter, we received some proposed amendments from James Ingram, for which the co-chairs are grateful. Michael made some amendments in response to these proposals. The proposed Group Charter can be read here.
The co-chairs now propose that we begin the 30-day election period for the approval of the revised Group Charter this Thursday 9 December 2021. The election will conclude on at 23:00 UTC on Sunday 9 January 2022. The method for voting will be to register your approval or disapproval on a dedicated page on the Community Group Wiki. If for any reason you are unable to sign in to the Wiki but still wish to vote, you can alternatively register your vote via the public-music-notation-contrib mailing list. Michael will send full instructions for how to vote at the beginning of the election period on Thursday 9 December.
Adrian has completed the migration of the last details of the old specification to the new specification, together with a list of the details that have intentionally not been migrated to the new specification (in the first section of the old specification document, Status of this document). This closes issues #253 and #223.
Issue #265 is also now closed: a number of elements with similar names in different contexts have now been renamed to avoid problems when validating against the W3C XML Schema. The following elements have been renamed:
<directions> (global) is now <directions-global>
<directions> (part) is now <directions-part>
<directions> (sequence) remains <directions>
<measure> (global) is now <measure-global>
<measure> (part) remains <measure>
The MNX converter has yet to be updated to conform to these latest changes, but Adrian plans to do that imminently.
Issue #266 has also been addressed, clarifying that <score> elements can use <layout> elements without requiring any <page> elements, to satisfy use cases where you need to describe a layout but no specific page information is required, for example to produce a single system of unspecified width (like Finale’s Scroll View).
We have now reached consensus on the long-standing issue concerning the grouping of parts (issue #185), and thanks to the work of Christina Noel to summarise the consensus view, Adrian will now prepare a pull request to work this into the specification.
In line with the revised Group Charter, the co-chairs have closed the remaining issues related to the proposed MNX-Generic format, since that is not within the scope of the community group’s work. As a corollary, we have also decided to remove the MNX-Common tag from the GitHub issues, since all open issues in the MNX project relate to what is now known simply as MNX.
The next co-chairs’ meeting will be on Tuesday 4 January 2022.
Michael has produced a draft of the updated Community Group charter that is now ready for review, which you can read here. If you want to compare the revised version with the current version, you can click here. The revisions extend the scope of the Community Group’s work to include the proposed new musical instrument data project, updating the description of the MNX specification to reflect the current status, updated information about the deliverables produced by the Community Group, and made some smaller edits that reflect the current working practices of the group.
To comment on the revised charter, please send an email to the public-music-notation-contrib mailing list (archives here). We apologise in advance for the higher than usual traffic on this mailing list, but this is a crucial step in the work of the community group, so we ask for your forbearance.
Please make any comments about the proposed revisions via the mailing list by Monday 6 December 2021. We plan to start the 30-day election process to approve the revised charter later that week, with the aim of having the revised charter approved early in January 2022.
A proposal for uniform style properties for MNX has been put forward by Joe Berkovitz (issue #263) that has generated some excellent feedback, and since this is an area of particular importance it would be great to have more contributions from other group members.
Another issue that has been actively discussed recently concerns re-use of element names in different contexts (issue #265): it appears that this will be not only potentially confusing but will also present serious obstacles for code-generation based on the XML schema. The proposed solution is to rename the elements, and Adrian will put forwards a concrete proposal.
Adrian continues to make progress on the project to audit the old specification document to bring things over to the new specification (issue #253), and to build a list of elements proposed in the original specification that are insufficiently concrete to be moved over as-is, or have been decided not to be done in MNX 1.0. Adrian is close to completing this task now.
Musical instrument data
Michael and Daniel met last week with Jeremy Sawruk and Simon Smith, who have expressed an interest in co-editing the proposed musical instrument data specification that is currently under discussion. The co-chairs would still welcome hearing from anybody who would be interested in taking on any part of the responsibilities for editing this specification, or potentially helping out in ancillary ways such as building software tools to manage and marshall the required data. If you might be interested, please contact Daniel via email.
The project cannot move forwards formally until the charter revision has been approved, but assuming it does so, the plan will be to bring together the co-chairs and the parties interested in playing a role in co-editing the specification together to start drafting a set of use cases that can be discussed by the wider community group and which will eventually form the basis of scoping the new project.
Date of next meeting
The next co-chairs’ meeting will be on Tuesday 7 December 2021.
Michael’s current plan for revising the Community Group Charter is to create a new page for the revised Charter in the wiki, starting with the existing Charter and then revising it on the wiki so that there is a good audit trail for the changes.
Approving the Charter requires an election process and requires a two-thirds majority of votes cast to secure the approval. The co-chairs are considering how to conduct this election and are considering using the wiki for the election process as well.
Michael aims to complete the process of revising the Charter, including the 30-day election process, by early January 2022.
There has been a lot of discussion on a wide variety of issues since the Community Group meeting.
Adrian has already brought over a number of the algorithms from the original specification into the new specification, and aims to bring over the remaining small details from the original specification to the new one by 12 November, so that the old specification can be properly deprecated. As part of this process, Adrian has implemented some changes to the docgenerator tool to allow nicer formatting of the algorithms that are used to describe the micro-syntaxes in the specification.
Adrian is also devoting some time to tending to the open issues and in particular to breaking down larger issues into more atomic, actionable ones, in the service of moving towards a definitive list of tasks for the version 1.0 specification milestone.
We are also interested in exploring the use of GitHub Discussions as a means of allowing more detailed discussion that spans multiple issues. Adrian will look in more detail at the capabilities of the Discussions feature and determine whether or not it seems suitable for our use.
The default branch in the MNX repository has been renamed to main (issue #233).
The proposal that the Community Group should take on an additional project of building a database of structured data about musical instruments was received enthusiastically at the most recent meeting. The first step towards this is to update the Charter to include this project as within the scope of the Community Group’s areas of work, which Michael is taking care of.
Two people have so far expressed an interest in becoming editor or co-editor of the new specification. The co-chairs will schedule meetings with these people to explore this further soon.
In the meantime, if any other group members are interested in taking on the role of editor or co-editor, please let the co-chairs know.
The next co-chairs’ meeting will be on Monday 22 November 2021.
We recorded the meeting on Zoom and have posted it online at YouTube. Zoom provides an automatic transcription feature, so there is also a complete transcript available via closed captioning. The video starting times for each part of the meeting are included in the headings below.
The following people attended the meeting via Zoom:
Michael Good, MakeMusic (co-chair)
Adrian Holovaty, Soundslice (co-chair)
Daniel Spreadbury, Steinberg (co-chair)
Chris Cianflone, MakeMusic
Cyril Coutelier, Flat
Roger Firman, Golden Chord
Mark Green, MakeMusic
Andrew Hankinson, Oxford University
Marco Herrera-Rendon, MakeMusic
Dominik Hörnel, capella-software
Reinhold Hoffmann, Notation Software
Kazuhiro Hoya, Japan Commercial Broadcasters Association
Peter Jonas, MuseScore
Martin Keary, MuseScore
Jeff Kellem, Slanted Hall
Steve Lee, W3C
Christina Noel, Musicnotes
Introduction to the Music Notation CG (3:25)
Michael Good began with a short introduction to the work of the W3C Music Notation Community Group, and the pre-existing specifications that were brought under the auspices of the CG when it was formed in 2015, MusicXML and SMuFL.
Douglas Blumeyer asked about where the CG activity is happening. Christina Noel replied that if you want to get involved in the activities of the group, the majority of that activity is happening in the GitHub repositories for the main specifications.
Progress update since last meeting
Each of the co-chairs provided an update on the current projects undertaken by the Community Group.
MusicXML 4.0 (12:23)
Michael provided a brief overview of the new features and improvements in MusicXML 4.0, which was released in June 2021. Michael expressed his particular pleasure and pride in the revised MusicXML documentation, which has been wanted by the software development community for 20 years, and which will be of huge benefit to developers in the future. Many of the other improvements are very beneficial, particularly in handling scores written in concert pitch while retaining instrumental parts in transposed pitch. Machine listening features that will benefit applications like SmartMusic, Antescofo, Metronaut, etc. have also been a focus.
There are no current plans for MusicXML 4.1, but community group members are welcome to submit ideas and requirements by creating new issues in GitHub.
SMuFL 1.4 (20:06)
Daniel provided a brief update on the new version of SMuFL, version 1.4, that was completed in March 2021. No work on SMuFL 1.5 is currently ongoing, but it is hoped that work will begin in the first half of 2022. The focus for that release is not yet determined, but the expectation is that it will be focused on further enrichment of the font-specific metadata format, particularly with regard to management and meaning of optional glyphs.
Mark Green asked whether any consideration had been given to adding information to the font-specific metadata for the SMuFL version of specification a font conforms to. Daniel recommended that Mark raise this as an issue in the GitHub repository and that it would be considered for implementation in SMuFL 1.5.
Documentation generator for MusicXML and MNX (30:13)
Adrian talked about the reasons why he decided to build a new document generation tool to provide high-quality specification documentation for both MusicXML, which had been using documentation from an old version of Madcap Flare, and MNX, which had been using the Bikeshed specification generator.
Adrian built a new platform on top of the Django framework that allows you to run a locally-hosted web application to enter the structured data about the elements, attributes and data types in an XML-based specification, and then generate a complete web site for the specification.
The document generator system has a good deal of infrastructure around providing structured examples for the format being documented, so that all of the elements and attributes in the example are cross-linked to the relevant documentation.
Steve Lee asked whether he could get the URL for the example provided in the spec. Adrian explained that every element has its own permanent URL.
James Ingram asked whether it would be possible to add code folding to the examples. Adrian said that he thought this was a good idea, and could be implemented, with the only reservation that the highlighted markup for a particular example would probably need to be always expanded.
MNX specification update (39:03)
Adrian talked about the ongoing work on the MNX specification, and in particular the large amount of work that went into the transition of the old Bikeshed-based spec into the new documentation tool.
Adrian outlined the benefits of MNX’s design, and in particular its desire to be highly semantic and with a clean separation between musical content and presentational or styling information. The format that is emerging is indeed strongly focused on semantics, and as a group we are navigating these sometimes tricky grey areas quite successfully.
The philosophy for developing MNX is to be example-driven, and pages like the comparison between MNX and MusicXML encoding are a strong focus for the development work. Michael stepped in to say that some of MNX’s design decisions make the format much more suitable for use as a native format for music notation applications than MusicXML, which is one of the strong benefits of the new format over MusicXML.
As a demonstration of the power of the semantic-driven approach being taken for MNX, Adrian showed a page of music in which music for multiple players are condensed down onto a single staff, something which is not easily possible in MusicXML, at least not taking a semantic approach. MNX, however, makes this possible by encoding the part elements (i.e. the music for each player) separately, and then there can be multiple separate score elements that are effectively a rendering of the semantic parts into a particular layout, determining the allocation of parts to staves. There are still some tension points to be resolved in this area, and Christina Noel and James Ingram appealed to other members of the community to join in this work.
The next steps with MNX are to put together the definitive list of remaining work for MNX 1.0 by assigning issues to the 1.0 milestone.
Jim DeLaHunt asked whether the MNX Converter project is one-way or two-way: currently it’s one-way (MusicXML to MNX), but Adrian expressed a willingness to make this two-way in future.
Steve Lee, as a new member to the group, asked about the plans for MNX, as to whether it is envisioned as a successor to MusicXML, and how we plan to get buy-in from software developers. Adrian replied that yes, it should ideally become the successor to MusicXML, and Christina Noel expressed that Musicnotes is already looking into supporting it. Adrian also expressed that he would draw upon Michael’s experience in building adoption for MusicXML.
Adrian also recommended that anybody interested in following the work on MNX should follow the blog and sign up for the public-music-notation-contrib mailing list.
Reinhold Hoffmann asked for an estimation of the realistic timeline for when MNX 1.0 might be ready. Adrian replied that there would probably be no down-side to starting implementation now, since the existing parts of the stable are considered to be stable. Reinhold clarified that he is interested in knowing when there will be sufficient momentum behind the format to cause multiple companies to decide to allocate resources to implementing the format. Adrian replied that this is really a difficult question to answer in general because every company’s priorities and level of resourcing are different. Michael suggested that, based on his experience with MusicXML, which took off once it reached version 1.0, that might be a good point to really determine the point at which it makes sense to start working on MNX implementations.
New possibilities for community group work
Instrument data (1:10:40)
Daniel talked about the idea, originally brought to the group by Daniel Ray of MuseScore, to build an open database of structured data about musical instruments for use in music notation software.
This idea was met with enthusiasm by the group, and several members immediately started sharing ideas and possible data sources to help get the project off the ground, including suggestions to reach out to musicologists, to the Musical Instrument Museums Online organisation, to refer to the existing taxonomy of more than 1000 instruments provided by Musicbrainz, and more. Mark Green suggested that it would be great to be able to include pictures (perhaps icons, photos, line drawings) of each instrument, and that localisation (of names, playing techniques, etc.) could also be valuable.
The co-chairs agreed that they will discuss this proposal some more, do some further research, and report back to the community group.
Non-Western music notation (1:27:31)
The group is not restricted by charter to focus purely on Western music notation, but the co-chairs feel that the current community group members don’t possess the necessary expertise to be able to develop formats for non-Western notation formats.
James Ingram says that he feels that once MNX 1.0 is complete, we may well find that support for some other notations, such as Asian notation systems, are reasonably close to Western tablature, and that the parallels between these notations might mean that some of the work has been done. Michael pointed out that the group’s work is guided by need and demand expressed by the group, so we do not necessarily have a strong long-term plan that already takes in these notations, but we remain open to the possibility of working on it in future if the demand emerges.
Updating the group charter (1:33:09)
Michael outlined the current state of the Community Group charter, which has not been significantly updated since the inception of the group in 2015. As the work on MNX has developed, some of the existing information in the charter has become outdated, and the co-chairs propose revising it.
Peter Jonas expressed surprise that the charter is sufficiently focused that it could go out of date. Michael explained that the original charter was drafted by original co-chair Joe Berkovitz, and that he had brought his experience as chair of the W3C Web Audio Working Group to bear on the process of drafting the charter. Michael pointed out that it’s common for both community and working groups to go through a process of re-chartering.
Michael has volunteered to take the lead on revising the charter and will report back to the group in due course.
Planning for in-person meetings (1:38:01)
Michael outlined the next possibilities for when we might be able to get together again in person, with the proposal that we would resume in-person meetings along with Zoom meetings. Spring 2022 provides four strong possibilities for in-person events:
Musikmesse, Frankfurt, Germany (29 April-1 May 2022)
The NAMM Show, Anaheim, CA (3-5 June 2022)
TENOR Conference, Marseille, France (9-11 May 2022)
Music Encoding Conference, Halifax, Canada (19-22 May 2022)
These events represent a balance between industry events and academic conferences, and Michael asked for feedback from the group about any preferences.
Mark Green asked whether it is typically possible to have virtual attendance at these in-person meetings, and Michael explained that this is not usually the case because the network facilities at these kinds of events tend not to be too good.
Jim DeLaHunt expressed his desire to see stronger cooperation between the W3C Music Notation Community Group and the MEI community, and perhaps setting up a meeting at the Music Encoding Conference would be a good opportunity to do that.
Jim DeLaHunt asked about converters between MNX and MEI, and wondered whether it might be possible to include MEI in the MNX by Example page. Michael cautioned that since there are hundreds of existing formats out there, and we might not be able to do a great job of managing examples in lots of other formats, and proposed that we in the community group ought to focus on our own formats. Adrian agreed that it would certainly be good to see the MNX Converter project become more powerful.
Meeting closed (1:52:01)
Michael closed the meeting by thanking everybody for their participation and provided links to how to join the group for any participants who are not already members of the group, and how to follow the specific GitHub repositories for each of the active projects.