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.
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.
Issue #304 concerning the documentation clarification for “none” clefs is complete and the pull request for issue #330 concerning broadening the set of SMuFL accidentals will be accepted straight after the meeting.
Now focus switches to issue #278 concerning the inclusion of multiple part documents within the same compressed MusicXML file.
MNX
The co-chairs have reviewed the discussion on issue #193 and have agreed that we can remove beams as structural elements and move towards a scheme of determining beams both in terms of a set of global document-wide rules for particular meters or classes of meter, and at a per-event level (for example, to define things like secondary beam groupings and the directions of fractional or broken beams). The MNX converter project and MNX Common by Example page will both be updated to remove the encoding of beams for the time being, and we will return to the nitty-gritty of defining beams in the near future.
The co-chairs also discussed issue #192, concerning the removal of the concept of profiles and the fall-out of the exclusion or inclusion of the specific items enumerated in the specification that are explicitly beyond the scope of the proposed standard profile, as was (including overriding the time and key signatures for a subset of parts, allowing noteheads on the same stem to have different note values, and so on). Adrian will create issues to cover the most important of these so that we can foster some community discussion in due course.
Next meeting
The next co-chair meeting will take place on Tuesday 29 September 2020.
Michael has completed issues #293 concerning virtual instrument changes and #308 concerning the design of inverted brackets. The next issue to be tackled will be #304, concerning a documentation change clarifying the use of invisible clefs.
Michael has added a new issue #330 concerning the expansion of the ranges of SMuFL accidentals that can be specified for MusicXML accidentals, which the co-chairs agreed should be part of the 4.0 scope.
Following that, the next issue to be tackled will be #278 concerning the handling of parts within the same document.
MNX
Mogens Lundholm opened issue #2 in the mnxconverter repository that Adrian has fixed. While he was working on the fix, Adrian created issue #193 for discussion concerning the nesting of tuplets and beams with the goal of getting feedback from other developers. If you are involved in the development of an application that could either create or consume MNX files, please do provide your feedback on this issue.
In the last co-chairs’ meeting, we agreed that we would give issue #192 two weeks for community discussion before proceeding to remove the concept of profiles from MNX. In the absence of a clamour against the idea, the co-chairs have agreed to proceed, so Adrian will now create a pull request to enact this decision.
One of the issues raised in response to this issue concerns whether the group charter still accurately reflects the priorities of the community group, and the co-chairs agree that we should review the charter before the end of the year.
SMuFL
Michael has raised issue #133 concerning the duplication of assignments from SMuFL glyphs to glyphs in the Unicode range for musical symbols. Daniel has assigned this issue to the SMuFL 1.4 milestone.
Michael has completed work on issue #249, concerning multi-measure rests which should not be able to have an empty body.
The next work item will be the first new feature to be added in MusicXML 4.0, as described in issue #293, which will provide a means of changing the virtual instrument sound for a doubling instrument, analogous to the existing means of changing the MIDI sound. Michael has a proposal in mind and will prepare a pull request with the proposal soon.
MNX
Adrian has completed the work required for issue #191, renaming MNX-Common to MNX. Following directly on from this is issue #192, concerning the removal of the concept of profiles from MNX. The co-chairs agreed that we will give the community time to think about and comment on this proposal, so we will discuss that feedback in the next co-chairs’ meeting.
The co-chairs discussed the interpretation content section of the specification, which currently still references the MNX-Generic specification. The specification currently discusses use cases like swing, interpretation of tempo without explicit tempo values, and grace notes; ideally we would do away with these elements and find more semantic ways of capturing these performance issues. We will create an issue in due course to capture any further use cases and come up with proposals for higher-level ways of encoding them, to see if this can be removed from the MNX specification without losing capability.
Next meeting
The next meeting of the co-chairs will be on Tuesday 1 September 2020.
w3c/smufl
