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 initial task of the Community Group is to maintain and update the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle new use cases and technologies, including greater use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications.
MusicXML 4.0 was released last week and the final community group report has been published on the W3C web site. The musicxml.com web site has now been updated such that the links to the documentation, tutorial, and other similar resources are now redirecting to the final community group report.
If you participated in any of the discussions around MusicXML 4.0 features or documentation, or otherwise made any contributions to the development of this version of the specification, please take a moment to make your licensing commitment.
Michael wants to thank everybody who played a part in building this new version of MusicXML 4.0.
In the process of finalising the MusicXML 4.0 community group report, there were a few remaining small improvements to the docgenerator tool that were merged by Adrian.
Now that the MusicXML 4.0 community group report has been published, Adrian’s attention will return to completing the migration of the existing MNX Bikeshed specification into the docgenerator tool. Once this remaining work is completed, the group as a whole will be able to return its attention to the further development of the MNX specification.
The next co-chair meeting will be on Tuesday 22 June 2021.
Thanks once again to everyone in the Music Notation Community Group who has contributed to MusicXML 4.0 development. This release addresses many long-standing issues with the format, and allows MusicXML to better support new types of applications.
Special thanks go out to Adrian Holovaty, who developed the documentation system that we used to produce the new report. His work allowed us to update, simplify, and expand the MusicXML 3.0 documentation that Mark Johnson originally developed at MakeMusic in 2012. The move from Flare to open source tools will make the documentation more maintainable for future versions.
Since the previous draft, we have added examples for all MusicXML elements*, added a version history, and updated the tutorial based on Jeremy Sawruk’s review. Adrian Holovaty has fixed all known issues with the documentation generator, so everything now be accurate.
There is a lot of documentation here so we expect there are still some errors left to find and documentation to be clarified. Any reviews of this draft over the rest of this week will be much appreciated. If you find a problem or have a suggestion, please raise an issue at https://github.com/w3c/musicxml/issues.
We are still planning to publish the final version of the report in one week’s time on June 1. Thank you for any assistance you can provide in our final week of work on this new MusicXML update.
*Except for deprecated elements and the other- extension elements.
The only remaining issue in the MusicXML 4.0 milestone is #411, concerning switching the licensing from the CLA to the FSA for the publication of the final community report.
One big milestone in this new and improved documentation for MusicXML: for the first time, every single element in MusicXML now has an example in the documentation.
Michael plans to publish a new draft later today and will send a separate announcement with its location. Community members are encouraged to review this draft and report any outstanding issues as soon as possible. The plan is still to publish the final community report on Tuesday 1 June, so please review the draft at your earliest convenience.
Adrian has continued to work on the docgenerator tool in support of Michael’s work on the MusicXML 4.0 documentation, though now that the MusicXML 4.0 documentation is almost complete, the expectation is that there will be much less work on tooling at this point.
Adrian has continued to migrate old material from the old Bikeshed-based spec to the new docgenerator spec, including stem directions, colour, and so on, and published a new revision today, which can be read here. All of these migrations are simply transferring existing material to the new specification and making no functional changes.
For the coming period, Adrian will continue to migrate further material from the old specification to the new. He expects to have some specific proposals about some of the existing elements that could either be reworked or omitted, which he will bring to the community shortly.
The next co-chairs’ meeting will be on Tuesday 8 June 2021.
Michael has opened and closed issue #403 concerning adding a SMuFL attribute to child elements of the percussion element to accommodate a wider range of pictograms for percussion instruments, specifically the stylistic alternates for some of them. The pull request (#404) implements this and also includes the necessary updates to the documentation.
There has been some discussion on the proposal in #401 to deprecate the DTDs with the release of MusicXML 4.0, and based on the feedback received from the development community Michael has decided to postpone this decision to a future version.
Issue #106, concerning a clarification of notes of different durations on the same stem, now has an example to show how this should be encoded in MusicXML and has now been closed.
We appealed for feedback concerning issue #280 for tips for using code generation with MusicXML, and we have received some good feedback that can now be incorporated into the tutorial to help future developers.
There are a few issues remaining with the docgenerator tool that are causing some minor hold-ups in the completion of the documentation, and Michael and Adrian will get together later this week to try to unblock the remaining work. Michael has also created a pull request (#234) in the MNX repository to update the docgenerator tool with some changes that are necessary for anybody else in the community who wants to build the MusicXML documentation for themselves, and Adrian will review and hopefully merge that pull request soon.
Michael has added the MusicXML 4.0 version history into the current draft of the documentation with links to not only all of the issues involved but also directly to the affected elements, which will make it very easy to look at the changes in detail.
Adrian has been making some further changes to the docgenerator tool to accommodate the new visual design introduced for MusicXML into MNX, and has made a start on moving material from the old Bikeshed spec into the new system, though this is throwing up some questions about how to split up the information that needs further thought. You can see the new visual design in the current draft here.
The next co-chairs’ meeting will be in two weeks on Tuesday 25 May.
The documentation is built using the generator tool that Adrian Holovaty initially created for MNX. It takes the MusicXML 4.0 schema and converts it into a Django database, which we then edit to add examples and additional content like the tutorial. Edward O’Riordan from Soundslice contributed to the graphic design.
We believe this version of the documentation has several advantages compared to the previous documentation available for MusicXML 3.0, besides being up to date with the latest 4.0 features:
The documentation now hides all the W3C XML Schema implementation details like complex types, attribute groups, and element groups. These are internal building blocks for the schema but of no immediate concern to MusicXML authors and developers. Now all you see are the parts of the schema that do matter to authors and developers: elements, attributes, and simple types (e.g. enumerations, regular expressions, different types of numeric values).
The examples and the element documentation are automatically linked together. You can click on any element within an example and get taken to the element documentation. Within the element documentation, you automatically get a list of all the examples that use that element.
Please take a look and let us know your thoughts. The documentation is not yet complete, but we think it is at a good enough state to be reviewed. We have brought over all the examples from the MusicXML 3.0 documentation, as well as the tutorial.
We know of four outstanding sets of issues that we are currently working to fix:
The documentation for some complex types is being generated incorrectly. Some choices and sequences are not displayed accurately. Everything is correct in the database representation; there are some bugs in the automatic text generation that we need to fix.
We need more examples. This is especially true for features added in MusicXML 3.1 and 4.0, but also for some older features where the MusicXML 3.0 documentation missed an example or had an incorrect example.
We need to add the version history.
The graphic design is still a work in progress.
If you have general comments and suggestions about the documentation structure and layout, please raise those in our main GitHub documentation issue 353. If something is incorrect in the description or example for a particular topic, please raise that as a separate issue if that seems appropriate. If you want to collect a bunch of comments in a single post in the main GitHub issue, that’s fine too.
We look forward to hearing your thoughts on the new documentation! We hope that you agree that it is a big step forward for making MusicXML easier to use and understand. But if you don’t, please let us know that too with suggestions on how to improve things.
Michael has been making excellent progress on the MusicXML 4.0 documentation (#353), working in concert with Adrian and his colleague Edward to address issues of both functionality and aesthetic appearance. Michael is hoping to release a draft of the MusicXML 4.0 documentation for review by May 1, 2021. This draft will be missing a few examples for new features added in MusicXML 3.1 and MusicXML 4.0.
Because there needs to be some time to review the documentation and finish off some small details, Michael proposes that the planned release date for MusicXML 4.0 be pushed back by one month to June 1, 2021.
One remaining issue that Michael needs some assistance with concerns documenting some tips and tricks for using code generation tools (#280). If any community members have any tips and tricks they would be happy to share, please add some details to this issue as soon as possible.
Michael furthermore proposes that the DTDs should be officially deprecated as of MusicXML 4.0 in favour of the XSDs for future versions. He will create an issue for community discussion in due course.
Adrian has continued to work on the docgenerator tool to support the MusicXML 4.0 documentation. He plans to add a search feature to the docgenerator tool in due course, though all of the pages will also be very easily indexed by search engines such as Google so it should be easy to find individual pages within the published documentation from search engines, too.
The to-do list for the docgenerator tool is dwindling as the MusicXML 4.0 documentation nears completion, so the focus will soon return to completing the migration of the existing MNX spec from the old Bikeshed version to the new docgenerator version.
The next co-chairs’ meeting will be on Tuesday 11 May.
Michael proposes the addition of a new SMuFL attribute to the wavy-line element to allow the specification of specific glyphs from the Multi-segment lines range, and the co-chairs agreed that this would be a good addition, so Michael will add an issue for this and add it to the MusicXML 4.0 milestone.
Michael has also been testing the docgenerator system for developing the MusicXML documentation and has run into a few issues with the import of the existing MusicXML XSDs that need a bit more attention from Adrian before he can make further progress. Adrian will take care of these issues forthwith.
Adrian has continued to focus his efforts on the docgenerator tool for the MusicXML documentation, and these improvements will make the tool more robust for MNX in the process. Once the docgenerator tool is in good shape, Adrian will turn his attention to continuing to migrate the existing MNX specification to the tool.
The next co-chair meeting will be on Tuesday 27 April 2021.
Attention has now turned to building the MusicXML 4.0 documentation using the docgenerator tool, which has involved Michael and Adrian sharing feedback and progress – for more specific details, see below.
Michael welcomes feedback on the new features in MusicXML 4.0. If you want to build software or otherwise test against the new schemas, they are available here.
The final community report (FCR) for SMuFL 1.4 has been published (here and here) and work on this revision of the specification is now complete.
The SMuFL 1.4 FCR is released under the W3C Final Specification Agreement (FSA), under which members of the community group are asked to make a voluntary licensing commitment concerning the intellectual property they have contributed to the project. For more information, read a summary of the FSA.
When you are ready to make your voluntary licensing commitment for SMuFL 1.4, please click here.
There are no immediate plans to start work on SMuFL 1.5, but please feel free to continue to raise and discuss issues so that we can start to build a backlog of areas of future work.
Adrian has been expanding the MNX documentation tool to handle a variety of new concepts in its data model. All of these are a result of his work to make the tool able to handle the needs of MusicXML:
Multiple schemas (in order to handle MusicXML’s Score, Opus, Sounds, etc. schemas)
A concept of “site options” (a place to hold site-specific metadata that’s globally available; previously the site hard-coded MNX for this)
Ability to treat an element’s sub-elements as either an ordered sequence or a set of choices
HTML formatting support for all description text
Support for static pages and collections thereof (which will be used, e.g., for the MusicXML tutorial and other documentation pages that aren’t handled by the automatic “reference” part of the docs)
The README has been updated to provide instructions on how to import the MusicXML XSD into the docgenerator system.
Adrian and Michael have been working together to plan the logistics of migrating the MusicXML docs to this system. There are a few remaining technical to-dos, and then begins the process of data entry to get content copied over into the new system.
The next co-chairs’ meeting will be on Tuesday 13 April 2021.
The goal is for these issues to be completed by March 22. This means that MusicXML 4.0 will then be considered feature-complete. Michael welcomes comments and reviews for all of the outstanding issues.
After feature completion, attention will turn to the remaining documentation issues, and to the broader task of producing up-to-date MusicXML 4.0 documentation.
Daniel has closed the final two issues, #178 concerning some implementation notes for ranges that should use the metrics for text-based applications even in fonts for scoring applications, and #179, concerning the size of the glyphs in the tables in the specification.
SMuFL 1.4 is now complete, so the remaining tasks are to update the license in the specification to the Final Specification Agreement, and then to publish the release at its final URL.
Adrian has been working on the docgenerator tool in order to expand its capabilities to make it suitable for handling the documentation for MusicXML. Adrian has written an importer for the MusicXML XSD schema files, to prime the docgenerator database with the raw materials to start building the updated documentation. There are still some open issues concerning the order of child elements that need to be addressed.
In the future, we can consider to what extent documentation needs to live in the XSD schemas or whether it would be sufficient for it to be shown in the online documentation. We will seek feedback from the community following the eventual MusicXML 4.0 release on this point.
Adrian continues to migrate material from the existing spec into the docgenerator tool and progress will pick up once the additional functionality needed to build the MusicXML 4.0 documentation has been added.
The next co-chair meeting is scheduled for Tuesday 30 March 2021.