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.
The co-chairs are beginning the process of organising a virtual meeting, which we propose will be part of the Technical Plenary/Advisory Committee (TPAC) 2021 meeting, which will be running as a virtual conference between 18 October and 29 October. During the second week of the conference, Working Groups and Community Groups can schedule meetings, and the co-chairs propose that our next CG meeting should take place under the umbrealla of the conference’s group meetings. We hope that this will promote awareness of the CG within and around the W3C. It will also allow members of the Music Notation Community Group to attend meetings for other CGs and WGs if they wish.
At the moment, we favour 1400 UTC on Thursday 28 October 2021, with 1400 UTC on Wednesday 27 October 2021 as our second choice. Please save the date in your diaries, and we will provide further information in due course after we have heard from the organisers of TPAC.
Adrian has changed the main page to point to the new documentation generated by the docgenerator tool and has also folded the introduction to MNX into the documentation. The co-chairs now consider the previous version of the specification effectively retired; there are a few small sections (for example, the pseudo-code for parsing the micro-syntaxes for MNX types) that are not currently accommodated in the new documentation, but we now recommend that anybody who wants to learn about MNX should use the new documentation and can ignore the existing specification.
Now that the old specification is effectively retired, focus can return to working on expanding the specification. Adrian is going to return to the issues that are currently under Active Review. Some of the current set are almost complete, so the first step will be to close some of them. The next major area that the co-chairs propose to tackle concerns the handling of issues like part formatting, and the differences between different presentations of the same material (issues #57 and #34).
The next co-chair meeting will be on Tuesday 3 August 2021.
Adrian has continued the migration of the old Bikeshed specification to the new docgenerator-based specification. He expects that this will be complete by the time of the next co-chair meeting in two weeks. The existing material is not being updated as part of the migration. Elements that the existing specification suggests could be migrated from MusicXML but providing no further details will be removed from the new specification and GitHub issues will be raised to capture these points for future discussion and specification.
Community group online meeting
The co-chairs would like to arrange an online meeting for the community group, tentatively expected to take place in September via Zoom. The co-chairs will provide a report on the group’s activity over the last year and we will have time for discussion about how the group’s work can proceed from here. We will circulate a poll to find an appropriate date and time for the meeting in due course.
Due to upcoming holidays, the next co-chair meeting will be Tuesday 20 July 2021.
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.