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.
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.
Pull request #340, which addresses issues #279 for representing transpositions in concert pitch scores, #55 for differences in clef between concert and transposing scores, and #39 for octave transpositions in concert scores, has been merged.
One further issue is still marked as in progress: #54, concerning enharmonic indications for concert and transposing pitch. Michael will tackle this issue next.
MNX
James Ingram has created two pull requests, #201 and #202, to cover the removal of the container element as part of the completion of the name change from MNX-Common to MNX. #201 is good to go, except that changes for the MNX by Example page need to be added.
The co-chairs discussed pull request #202, which concerns the creation of a new specification document to cover the mnx-container element, on the grounds that the group charter still talks about it. The view of the co-chairs is that it is vital the group charter reflects the true focus of work of the community group; however, with active development underway on both MNX and MusicXML 4.0, now is not the time to spend our limited resources and attention on changes to the charter. As always, the co-chairs invite feedback from the community at large if there are other ideas.
The co-chairs also discussed issue #198 concerning beaming. The community has expressed doubts about the usefulness and practicality of defining high-level rules for beaming, and the co-chairs agree that this idea can be deferred for the time being. We agreed that we would focus on how beams should be explicitly encoded, and Adrian will put together at least one proposal for how this might be done, and add them to the issue for discussion in due course.
Next meeting
The next co-chair meeting will be on Tuesday 27 October.
Issue #278, which describes the method to include the full score and separate instrumental parts in a single compressed MusicXML file, is complete. The next issue to be tackled will be #279, which caters for having a concert score and transposed parts, and along with it the following additional issues will also be covered: #39, concerning octave transpositions for instruments; #55, for clefs that differ between concert and transposed pitch; plus #54, which describes enharmonic spelling variation between concert and transposed pitch.
Issue #336 concerning the placement of figured bass was also briefly discussed and the co-chairs agreed that it can be included in the scope of MusicXML 4.0.
MNX
Pull request #194, which removes the beamed element from the spec and the MNX by Example page, has been merged. Consequently, issue #193 is also now closed. This means that at present there’s no way of encoding beams in the MNX specification, and defining the specification for beaming is now covered by issue #198, which we will return to in the near future.
The co-chairs discussed the beginnings of how beaming might be encoded and posited the creation of a new rules element that could house document-global rules for how the musical data in the file should be interpreted. Adrian will put together the beginnings of a proposal for how beaming could be defined as a series of rhythmic offsets into a bar (e.g. the positions at which primary beam groups should start and stop, given a nominal bar of notes of a specific duration) and we will discuss further with the community.
Adrian has also removed beaming from the MNX Converter in the short-term, as a reflection of the current state of the MNX specification.
Adrian has also created issues #195, #196 and #197, concerning the remaining ideas that were removed from the MNX specification as part of the work to remove the concept of profiles.
Next meeting
The next co-chair meeting will be on Tuesday 13 October 2020.
w3c/smufl
