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.
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.
Issues #53 (concerning the missing layout element from the print element) and #287 (concerning documentation for measure repeats) are both now complete and the pull requests have been merged.
Next up is issue #249 concerning multi-bar rests, which has a text element describing the number of bars in the rest, but this can currently be empty, which is not very helpful, since there’s then no way to know how many bars the rest represents. The plan is to change this so that the text element cannot be empty, which technically changes the format in a way that is not backwards-compatible, but we do not believe that anybody is relying on that behaviour.
Issue #322 was also raised, concerning the playback of repeats in MusicXML after a dal segno jump; MusicXML does not currently specify whether or not repeat endings should be played back after a dal segno jump. This seems like something that could be addressed in the next MusicXML version, and has been added to the MusicXML 4.0 milestone.
MNX-Common
After two weeks of discussion about issue #191, concerning the long-standing issue of how we should resolve the naming of MNX-Common and MNX-Generic, the co-chairs have decided that MNX-Common should be renamed as MNX, in accordance with the common practice of the community.
No immediate decision about the eventual name of MNX-Generic has been taken at this time; we will review this again when work on that specification is restarted.
As part of the naming discussion, there were a number of discussions concerning the idea of profiles, which were proposed as part of the original MNX-Common design as a means of declaring what kinds of notations can be expressed by a particular document, with a view to allowing applications to support different “levels” of MNX-Common.
However, as work on the specification continues, the co-chairs now feel that as part of the constant drive to keep MNX-Common focused on practicality, intelligibility and ease of use, profiles are contrary to those goals. The co-chairs believe that we can do away with the concept of profiles, provided we always specify precisely what the default behaviour for every kind of encoding should be, and take the hard decisions about precisely what can and cannot be encoded in MNX-Common. Adrian will create an issue for community discussion around this point.
Work on MusicXML 4.0 is still at the stage of taking care of documentation issues. Issue #62 concerning arpeggio signs and and issue #254 concerning bar repeats have been resolved and closed. Next up will be issue #53, clarifying what should happen when layout elements are missing from the print element, followed by issue #287, which is a further issue concerning documentation for bar repeats. Community members are invited to review pull request #323, which addresses issue #53.
Michael also opened issue #321 for slash notation in irregular meters and proposes bringing that into scope for MusicXML 4.0.
MNX-Common
Adrian has created pull request #190, adding repeat and jump elements to the MNX-Common specification. The aspect that is not yet completely addressed is determining the way of handling multiple codas and segnos; the co-chairs discussed the approach that should be taken, whether it makes sense to encode double coda and double segno explicitly, or to use a system of identifiers to disambiguate individual coda and segno symbols. It was decided that we should use the latter approach, and Adrian will update the pull request accordingly.
Adrian also created issue #191 concerning the ongoing question of the naming of MNX-Common. While it is still the view of the co-chairs that we should adopt MNX as the new name for MNX-Common, we invite the community to give feedback on this issue once again.
Adrian plans to split the MNX-Common by Example page into multiple pages to prevent it from becoming unwieldy. The co-chairs are also looking into alternative technologies for building the MNX specification, with a view to making it easier to create cross-links between the spec and the MNX-Common by Example page, and possibly for use with updated MusicXML documentation in future.
SMuFL
There is a pull request awaiting integration, which Daniel will take care of when he has made the necessary upstream change to be sure it won’t be overwritten the next time SMuFL is updated. Daniel also has a small list of glyphs whose canonical names should ideally be changed, but since there has been a commitment not to change glyph names since SMuFL 1.0, this needs to be discussed with the community to assess the impact. Daniel will create this issue soon.
Next meeting
The next co-chair meeting is scheduled for Tuesday 4 August 2020.
Adrian has updated the mnxconverter project to handle all of the repeat barlines and repeat endings examples given in the MNX-Common by Example page.
Up next, Adrian will update the MNX-Common specification to cover the repeat barlines, endings and jumps. Thereafter, Adrian will update the mnxconverter project to handle repeat jumps.
Once these tasks are complete, the next priority will be to add to the MNX-Common by Example page examples for part grouping, based on the community discussion that has been going on in the new issue #185. The plan is to base the new examples on the proposal for the staff-group element in this comment from James Ingram.
Next meeting
The next co-chair meeting is planned for Tuesday 21 July 2020.
Pull request #318 closing issue #291 has now been merged, and Michael is next planning to work on a pull request addressing issue #254.
MNX-Common
After discussion at the last co-chairs meeting, Adrian has continued to work on the examples for repeat endings and structures, and pull request #186 has been updated taking that feedback and some community feedback into account. The co-chairs discussed using a type value of discontinue (instead of stop) for the final ending in a repeat structure. Having made that change, the co-chairs agreed that this pull request is ready to be merged.
Two further pull requests will follow, one to add repeat endings to the MNX converter project, and one to update the MNX-Common specification in this area.
The co-chairs discussed issue #185. The co-chairs discussed closing some old issues. Issue #185 will remain open but should from now on be more focused on how parts should be grouped; the useful discussion on the other aspects, such as system and staff formatting (which is covered by issue #57), differences between scores and instrumental parts (covered by issue #38), and how to handle collections of related musical documents within a single MNX-Common document (already described in the specification, but which can be reviewed in in the new issue #188). The co-chairs encourage the community members who have created proposals in these areas to move the current state of each of those proposals to the relevant new issue.
The co-chairs see promise in the proposal worked on by the community in issue #185 described as the staffGroup element, and will work on including this in the MNX-Common by Example and the specification as the next priority, once the current work on repeat structures is complete.
The co-chairs also agreed that issue #138 should now be closed.
Next meeting
The next co-chair meeting is scheduled for Tuesday 7 July 2020.
Adrian has been working on a pull request (#186) for new examples added to the MNX-Common by Example page showing a proposal for how repeat barlines, jumps and markers could be represented. There are five examples added: three examples of repeats involving repeat barlines, and two involving jumps.
The co-chairs discussed the proposal and agreed that in order to accommodate repeat endings that are longer than a single bar, we need to separate the start and end of these structures so that they can be declared in different bars if need be. The co-chairs also discussed whether or not it should be necessary to encode the different types of D.S. jump (such as D.S., D.S. al Fine, D.S. al Coda) separately, and came down on the side of specifying them separately; this is not perhaps strictly necessary but makes consistency-checking of the overall repeat structure easier.
The co-chairs also discussed the issue of how the presentation of repeat jumps such as D.S. al Fine should be handled, since these often mix musical symbols with plain textual content. The text aspect of the elements will be removed for now, pending a wider discussion about how best to encode these kinds of markings in future, since they tend to occupy a grey area between semantic and presentational data.
The co-chairs briefly discussed the recent work being done by community members on the issue of how parts should be grouped in MNX-Common in issue #185, and will both review the discussion, comment on the issue, and potentially discuss in more detail in the next co-chairs’ meeting.
Next meeting
The next co-chairs meeting will take place on Tuesday 23 June 2020.
MIchael has completed the first pull request (#315) for MusicXML 4.0, updating version. Issue #291 is currently in progress. Michael’s plan is to start with some of the Documentation issues before progressing to the more substantive issues.
The co-chairs also reiterate that anybody who wishes to contibute to the project, whether it is in the form of participating in discussions on issues but more critically when working on pull requests, must join the Community Group and agree to the terms of the W3C Contributor License Agreement. If you do not join the group and agree to the CLA, we cannot accept your contributions.
MNX-Common
Adrian has been working on a proposal for repeat barlines and markers to address issue #174. The co-chairs had a discussion about the approach we might take in MNX-Common to encode repeat barlines, repeat endings, and coda/segno markings. Adrian will proceed along the lines of taking the attributes that are part of the barline and sound elements in MusicXML and consider how they might best fit into the existing structure of MNX-Common, perhaps in a new jump element. Adrian will work on the proposal in the coming weeks and will have something to share with the community soon.
Next meeting
The next co-chair meeting will take place on Tuesday 9 June 2020.
Following the discussion in the recent Community Group meeting, Michael created issue #314 to canvass the community over the issue of whether or not the version number for the next version of MusicXML should be 3.2 or 4.0. There is a narrow majority in support of MusicXML 4.0 so this is what we are going to do. Michael will create an initial pull request to change the version number, copyright date, and switch the license back from the Final Specification Agreement (FSA) to the Contributor License Agreement (CLA), which is the appropriate license to use for the development process.
The co-chairs also discussed issue #313, which can be closed. Michael will review the outstanding issues in the MusicXML repository for those that will be deferred to MNX, ensure that a corresponding MNX issue exists, and then close those issues.
Adrian will next add some examples for transposing instruments to the MNX-Common by Example.
Adrian will add links to the new mnxconverter project to the various pages on GitHub that should have them, and Michael will contact our W3C representative to add a link to the mnxconverter repository to the CG home page.
Next up will be a proposal for how to encode repeats in their generality, including repeat barlines, repeat endings, and repeat jumps.
On the subject of how MNX-Common and MNX-Generic should be named, following the discussion at the Community Group meeting a couple of weeks ago, Adrian will start a new issue to capture any further feedback from the community.
Next meeting
The next co-chair meeting will be on Tuesday 26 May 2020.
w3c/smufl
