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.
w3c/smuflGroup'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.
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.
Pull requests for issues #37 and #23 have been completed and merged, so those issues are now complete. There has been some good discussion on issues #305 and #351 concerning the layout of percussion kits and staves, but Michael plans to park these for the time being in favour of working on some other higher priority items. At the moment, Michael is planning to next tackle issues #307 for polychord notation for chord symbols and #310 for bar numbering for multi-bar rests.
SMuFL 1.4
Daniel made less progress than anticipated over the holiday break on the remaining SMuFL 1.4 issues. As at the time of the last meeting, the single substantive issue remaining concerns numbered notation. Daniel is going to make a final determination over the next week or so whether we have a good enough planned implementation for this important area of notation to move ahead with it in SMuFL 1.4, or to instead defer it for a future release. Other than that, the remaining work is on implementing all of the new ranges in the Bravura font so that the final community report can be delivered.
Daniel anticipates that a beta of both the SMuFL 1.4 specification and accompanying Bravura font should be ready by the end of January.
MNX
Adrian has merged pull requests #205 which adds further beaming examples to the MNX by Example page and #6 which implements conversion of beams in the MNX Converter. There is a pending pull request #213 that adds support for cross-staff beaming, which Adrian will consider before merging.
Adrian’s current focus is on tooling for the MNX specification and associated documentation. Having reviewed a number of available tools for the generation of specifications and documentation (including Bikeshed, Sphinx, Read The Docs, et al), he is proposing the development of a bespoke tool for the creation of the documentation that can best meet the specific needs of documenting a complex XML schema and its elements and attributes.
The proposal is to create a Django-based web application that can be run on a local machine (rather than requiring a centrally-hosted application with its own approach to user identification and authentication, which is in conflict with the IP requirements of the W3C CLA) that can both generate the static pages that will form the public-facing specification and also plain text data files that can fit into the CG’s established workflows using GitHub pull requests to track changes.
Adrian is going to pursue some initial experiments in this direction in the coming weeks. If at all possible the CG will use this new tool not only for the MNX specification but also for the MusicXML 4.0 specification.
Next meeting
The next co-chair meeting will be on Tuesday 19 January 2021.
Daniel has been working on some of the remaining issues and still expects to complete the outstanding work before the end of the year as planned.
MusicXML 4.0
Issue #37 concerning notations shown above or below the staff has had some excellent community discussion, and Michael is now ready to create a pull request that will also cover issue #23.
Issue #305 concerning percussion staves with irregular staff gaps has also been subject to a lot of discussion, and the related issue #351 will probably be targeted by the same pull request in due course.
Community member Karim Ratib has created an HTML version of the current state of the MusicXML 4.0 schema which has prompted Michael to consider just how we will produce the final documentation for MusicXML 4.0. Michael is going to create an issue to cover this work and do some initial investigation into the tooling that might be useful for this.
MNX
Adrian is also considering how to move the current state of the MNX specification out of the Bikeshed format and into another format that will hopefully allow creation of documents closer in style and format to the MNX by Example page. There may be some overlap with the task of producing the MusicXML 4.0 community report.
Adrian has added support to the mnxconverter project for beam hooks, secondary beams and beams across barlines in the format described in issue #198 in pull request #6. Pull request #205 covers the required changes to the specification, and there are now five beam examples in the MNX by Example page. These pull requests are now ready for review.
Next meeting
The next co-chair meeting will be on Tuesday 5 January 2021.
Issue #283 concerning the representation of swing in MusicXML has now had its corresponding pull request merged. Issue #345 concerning updating the level of the International Phonetic Alphabet (IPA) symbols that can be used in the play element has also been completed. Issue #306 concerning the representation of guitar bends on notation and tablature now has a pull request (#350) ready for merging, subject to any further community feedback.
Issue #37 concerning the representation of items that appear above the top staff or below the bottom staff is the next item that Michael is planning to tackle.
There has also been some constructive discussion on issue #295 concerning Roman numeral analysis, and Michael will encourage those community members who have an interest in this area to work on a proposal for inclusion in the spec.
Given the current rate of progress towards the initial milestone, the current target date of the end of January 2021 seems unrealistic, and Michael has moved that date back to the end of March 2021.
MNX
There has continued to be a good deal of discussion about how to encode beaming in issue #198, and Adrian has begun to implement the latest proposals in code in the mnxconverter project; this is not quite complete at the time of the meeting (with beams across barlines and secondary beam groups yet to be implemented), but Adrian reports that it feels good, and the current state can be seen in pull request #6. Once Adrian had the converter working, he was able to produce some more beaming examples for the MNX by Example page, which can be seen in pull request #205.
Adrian’s plan is to continue rolling on with this work and will update these pull requests accordingly.
Upon the completion of the work on beaming, Adrian plans to work on formalising the encoding of grace notes in the MNX by Example page, since there is an initial specification of grace notes in the specification. Any discussion concerning these examples should be added to issue #206.
SMuFL 1.4
Daniel continues to work on the last few open issues in the SMuFL 1.4 milestone and he believes everything is still on track to hit the milestone of the end of December 2020.
Next meeting
The final co-chair meeting of 2020 will be on Tuesday 8 December.
There are currently 21 pull requests waiting to be merged, which constitute the majority of the issues targeted for this milestone. A couple of late-breaking issues (#156 and #157) concerning the final completion of the two oustanding ranges of Sagittal accidentals have been added to the milestone. Daniel is ready to merge in the existing pull requests, and a good number of these issues should be resolved before the next co-chair meeting. Work will then turn to updating the Bravura font and its metadata in accordance with the new ranges and glyphs in SMuFL 1.4.
MusicXML 4.0
There has been a good deal of discussion around issue #283 concerning how swing should be represented, and Michael has created pull request #346 with a concrete proposal as a basis for further discussion.
Michael anticipates that a possible next area of work might be issue #37, concerning a means of determining on which staves system-level items should appear.
MNX
Issue #198 concerning the encoding of beaming has been widely discussed and Adrian has provided some refinements to the proposal based on the community feedback. Adrian has expanded on the various use cases that were in question – for example, encoding beamed groups of grace notes within beamed groups of rhythmic notes, beams across barlines, and so on – and an updated proposal for how secondary and tertiary beams could be encoded has been added. We will await more community feedback, but the co-chairs feel that this approach looks promising enough that we anticipate starting work on a pull request to add these proposals to the MNX by Example page and the specification.
Next meeting
The next co-chair meeting is scheduled for Tuesday 24 November.
Michael is next going to submit a pull request for issue #336 for figured bass placement, and then will tackle another issue in an area unrelated to the most recent work on enharmonic spelling and transformation. Although he’s not sure what the next thing will be, he’s leaning towards implementing proper support for swing (issue #283).
In case community members haven’t already seen it, Michael has also written a post in celebration of MusicXML’s 20th anniversary, which you can read here.
SMuFL 1.4
Daniel has begun working on the issues in the SMuFL 1.4 milestone, and has created an initial set of pull requests addressing 16 of the 29 issues currently remaining open in the milestone. Community members are invited to review the pull requests.
At this stage, these changes affect only the SMuFL specification; once all of the new and updated glyphs and ranges are decided, work will then proceed on updating the reference font, Bravura.
If any community group members have any remaining issues they would like to raise for consideration in SMuFL 1.4, they are encouraged to do so in the very near future, as the scope of this update will shortly need to be fully settled if the planned completion target of the end of 2020 is to be met.
MNX
Pull request #201 to remove the container element from MNX documents has now been merged, with thanks to James Ingram for his work on preparing that pull request. This closes issue #192. Adrian has updated the MNX converter project to reflect these changes.
Pull request #202, concerning the addition of a separate spec for the MNX container, has been closed with no further action for the time being.
Adrian has also added four proposals for the encoding of beaming in issue #198, and invites feedback from the community. Adrian will develop a few more examples to capture cases like beaming over barlines, secondary beam groups, and beamed grace notes and add them to the issue, but we invite feedback from the community on the proposals as presented.
Next meeting
The next co-chair meeting is scheduled for Tuesday 10 November.