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 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.
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.
w3c/smufl
