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.
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.
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.
MNX
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.
Next meeting
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.
MNX
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.
Next meeting
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.
MNX
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.
Next meeting
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.
SMuFL 1.4
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.
MNX
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.
Next meeting
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.
SMuFL 1.4
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.
MNX
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.
Next meeting
The next co-chair meeting is scheduled for Tuesday 30 March 2021.
#382: Documentation for the Note names notehead supplement SMuFL range
The issue concerning Roman numerals for harmonic analysis (#295) is currently being worked on. The next major issues targeted for work are #305 and #351, which concern staves with irregular number of staff lines, primarily for untuned percussion.
Michael has reviewed all of the outstanding features that have hitherto been considered in scope for the MusicXML 4.0 release and proposes removing them from scope: #5 (SMuFL rest alignment), #6 (exact barline definitions), #54 (handling of enharmonic pitches for transposed and concert pitch scores), and #260 (generating IDs).
In their stead, Michael would like to bring a handful of issues into scope: #281 (cross-staff arpeggio support), #8 (documenting how the number attribute works when it refers to document vs. score order), #106 (documenting how to represent chords with notes of different durations), #355 (encoding invisible directions for analysis applications).
SMuFL 1.4
Michael recently raised issue #178 concerning some ambiguity in the specification of three ranges that include symbols usually shown in line with regular text characters. After discussing it in the meeting, Daniel has agreed that he will add the necessary clarification to the specification for the affected ranges and will publish an updated draft as soon as possible. Otherwise there has been no other specific feedback, so we are still on track to move to a final report within the next couple of weeks.
MNX
The MNX by Example page has been fully replaced with the new page driven from the docgenerator tool. It has two improvements: all the MNX examples have clickable XML element and attribute values, which will take you directly to the documentation for that element or attribute’s data type; the authoring technique for allowing the display of just the relevant section or the whole document is also much neater now and will make the examples easier to write and maintain in the future.
Adrian has also added the concept of attribute groupsto the docgenerator tool, which is needed for handling the richer data in the MusicXML schema and also for some aspects of the current MNX specification.
Adrian is also in the process of migrating some of the existing specification to the new docgenerator tool, with the goal of being able to retire the current Bikeshed-generated specification as soon as possible. This will also require the addition of features to provide preamble and front matter, which is needed for MusicXML as well.
Ahead of the next meeting, Adrian plans to complete the migration of the fully-specified elements and attributes from the spec to the docgenerator tool, and to add the remaining concepts and data types required to allow the MusicXML documentation to be driven from the tool (specifically, choices, sequences and element groups).
Next meeting
The next meeting will be on Tuesday 16 March 2021.
Michael has also brought #382 into scope for this release, which is a small task to include the new Note name noteheads supplement range in SMuFL 1.4.
Although excellent progress is being made on the remaining tasks in the MusicXML 4.0 milestone, Michael now feels that the target date of the end of March 2021 for completing this release is now too aggressive, and proposes moving it back by one month to the end of April 2021, with an ambition to reach feature completion by the middle of March, leaving the remainder of the time to complete the documentation.
The next issues Michael plans to work on are issues #335 (concerning pedal lines), #259 (adding an XML catalog file) and #382 (note name noteheads).
SMuFL 1.4
After Michael spotted a few incorrect details in the last version of the SMuFL 1.4 draft, Daniel has published an updated version here. Unless any further errors or omissions are identified in the next two weeks, the plan is to move to a final community report at the end of February 2021.
MNX
Adrian has continued to work on the docgenerator tool for MNX, and has implemented one of the two remaining missing features that was preventing the replacement of the existing MNX by Example page with the new MusicXML and MNX Compared page, namely the ability to switch between showing the full MusicXML or MNX document and only the area of interest. For more details, please see this GitHub commit message.
The only outstanding task prior to the replacement of the MNX by Example page is the ability to define the order in which the examples will appear, and Adrian will work on this next.
Next meeting
The next co-chairs meeting will take place on Tuesday 2 March 2021.
#205: documentation of how to handle redundant guitar tab staves in documents that encode notation+tab
#285: fixing imported schema location attributes in the schema for XML and XLink, so they now validate in Python’s XML parser more easily
#288: adding a type attribute to the level element to encode the start and stop of a level
#292: better documentation for the staff-type element
#311: better documentation for the rehearsal element
Issue #335 has been brought into scope, to allow the encoding of a piano pedal line without an initial vertical stroke.
Michael next plans to work on the listen element, covered by issue #294, and polychord and altered bass note formatting for chord symbols, covered by issue #307. There are now 22 remaining open issues in scope, and 36 closed, so progress towards the milestone is currently at more than 60%.
SMuFL 1.4
All of the remaining issues in the SMuFL 1.4 milestone have now been closed, and an updated editor’s draft with all of the changes has now been published, which you can read here. A summary of the changes in this version, with links to the relevant issues, can be found here.
To accompany this draft, Daniel has also released a new version of Bravura, version 1.392, that implements all of the SMuFL 1.4 changes. Feedback from the community on the new glyphs is particularly welcome.
Depending on what feedback is received in the coming days, further changes may be needed, but currently the plan is for SMuFL 1.4 to proceed to becoming a final report by the end of February 2021.
MNX
Adrian has been making improvements to the documentation system, tracked in issue #223, adding a data model for data type options so that the values of attributes can be defined in a strict fashion.
There is also now a new page in the documentation called Comparing MNX and MusicXML, which is intended as the eventual successor to the existing MNX by Example page. Once Adrian has implemented the missing features – the ability to focus in on just the relevant parts of the mark-up in each example, and the ability to order them reliably – then the previous page can be retired.
The next job is to model the complex types so that it can be possible to use this documentation system for MusicXML as well as MNX, and to make it possible to create additional pages in the documentation to house more discursive material such as tutorials, examples, and so on. Beyond that, Adrian will continue to migrate the existing MNX specification material into the new system.
Next meeting
The next co-chairs meeting will be on Tuesday 16 February 2021.
Issues #261 (lyric alignment), #282 (adding part name as a credit-type), #302 (discontinue type for pedal lines), #310 (measure numbering for multiple rests), #333 (clarifying the documentation for the transpose element), #349 (clarifying the interaction in the harmony element between specifying a kind of none and then specifying a root for the chord), and #352 (clarifying how certain kinds of chord symbols with suspended notes should be represented) have all been closed in the last two weeks.
Issues #28 (clarifying musical location after the last note in the bar), #43 (placement of dynamics and directions both with placement attributes), #362 (figured bass justification and alignment), #363 (adding new sound IDs), and #368 (doubling transposition above) have all been brought into scope for MusicXML 4.0.
29 issues remain open in the MusicXML 4.0 milestone. The next priority issues for work are #294 (the listen element) and #277 (clarifying which part different notes on the same stem belong to).
The co-chairs welcome feedback from the community for issues #295, concerning Roman numerals notation, #203 and #204, concerning guitar bends. With the planned deadline of trying to bring new functionality to completion by the end of February, timely feedback from the community on these issues will help to ensure that they are addressed in this version.
SMuFL 1.4
After further discussion between the co-chairs, we have decided to descope issue #80 (support for numbered notation systems) from the SMuFL 1.4 release, as there is sufficient uncertainty about the best way to approach this and precisely which conventions to support. In the interest of not delaying SMuFL 1.4 any further, we’ll therefore defer this to a future release.
Daniel is still planning to complete the necessary work on new glyphs in Bravura so that the new symbols are available by the end of January.
MNX
Adrian has been working hard on the documentation generation tool that was discussed in the previous meeting. Although work is still in progress, community members can take a look at the tool and try running it themselves on their local computers by following the instructions on the docgenerator page in the MNX repository. You can see the current output of the generator on the docs page.
Now that the tool is basically up and running, Adrian will now turn his attention to moving over all of the existing material from the current version of the specification and the MNX by Example pages into the new tool. There will also be some work on the visual styling to bring the output closer into line with the usual look and feel of W3C final reports and specifications.
All being well, it is also hoped that this new tool will be able to be used for the MusicXML 4.0 documentation. The tool cannot currently handle all of the complex types and ordered elements required by the MusicXML schemas, but Adrian will be working to continue to expand the tool to make this possible in the coming weeks.
At this stage, the co-chairs are not inviting feedback on the tool or its output: both will continue to evolve quickly over the next few weeks. Once the co-chairs feel the tool is complete enough for feedback to be useful, we will be sure to let the community know.
Next meeting
The next co-chairs meeting is scheduled for Tuesday 2 February.
w3c/musicxml
