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.
There has been some good discussion concerning the proposal for how to encode multimeasure rests (issue #284), and Adrian has charted a course through the feedback provided by the community to settle on a new proposal which can be found in this comment. Michael pointed out that we are using the term “measure” rather than “bar” in MNX so we will standardise on this term when encoding multimeasure rests as well.
We welcome any further feedback from the community, but absent any major objections we plan to move this to the pull request stage in the near future.
Next co-chairs’ meeting
Due to holidays, the next co-chairs’ meeting will be in four weeks on Tuesday 16 August.
Adrian has created issue #284 with four possible approaches for encoding multi-bar rests in MNX. Some of the approaches use the new layouts system in MNX more than others, and the choice of proposal will probably come down to a decision about how much or little we want to use this system. The co-chairs discussed whether or not it is a requirement for multi-bar rests to have different configurations within the same part in different scenarios (using the same part in different layouts), and determined that this was not a requirement, which means that any of the proposals could be used. Community group members are invited to provide their feedback on the proposals.
The next co-chairs’ meeting is scheduled for Tuesday 19 July 2022.
Adrian has begun working on encoding multi-bar rests in MNX in service of issue #34, and will create a new issue with his proposal and one or two example documents within the next couple of days. We will be glad to receive feedback from community group members about this new proposal.
The next co-chairs’ meeting is scheduled for Tuesday 5 July 2022.
Community Group meeting: Thursday 15 September 2022
We have had confirmation from the organisers of TPAC 2022 that the Music Notation Community Group meeting will take place as part of the conference proceedings on Thursday 15 September 2022 at 0800 PDT (Vancouver time), 1100 EDT (New York), 1600 BST (London), 1700 CEST (Berlin), 0000 JST (Tokyo).
This will be an online-only meeting: there is no need to go to Vancouver in person for the TPAC conference to participate in this meeting. An invitation for the time and date has already been sent to the music-notation-public mailing list so you can add it to your calendar. Details for how to register for the conference (which is free of charge) and to attend the online meeting will be made available in due course.
Date of next meeting
Because this meeting was delayed by one week due to illness, the next co-chairs’ meeting will be in one week on Tuesday 21 June 2022.
The co-chairs had a productive discussion to guide the initial proposals for issue #34, concerning the differences between score and part layouts. Adrian had identified five specific areas that should certainly be considered: note spelling; stem direction; initial clefs; multi-bar rests; and cues.
After some discussion about different potential approaches to cues, the co-chairs agreed that we would discuss that issue separately, as there is sufficient complexity to warrant designing a solution on its own terms.
For note spelling, stem direction and clefs, the co-chairs agreed that it should be sufficient in most cases to encode an optional alternate spelling and stem direction to be used when the music is viewed at sounding or concert pitch (since MNX encodes everything at written or transposed pitch), with the additional proposal that it should be possible to define an alternative transposition for an instrument in each layout, and a corresponding alternate initial clef, to cater for simple cases defining mutiple layouts with different transpositions for the same instrument.
For multi-bar rests, the co-chairs agreed that it would be sufficient to define ranges of multi-bar rests in layouts in a simple way, and Adrian will begin the work on issue #34 by forming a proposal for the encoding of multi-bar rests, before proceeding to tackle note spelling, stem direction, and clefs.
Community Group meeting
We have not received any negative feedback that suggests that holding our next Community Group meeting as part of the hybrid TPAC 2022 conference will be a problem, so we will be submitting a proposal to the TPAC organisers to schedule our meeting on Thursday 15 September 2022 as discussed in the last co-chairs’ meeting. We will advise CG members on the outcome of this proposal as soon as we hear back from the organisers.
The next co-chairs’ meeting is scheduled for Tuesday 7 June 2022.
Pull request #282 which addresses the proposal for styling of MNX elements (issue #263) has been merged. You can read the specification for the style element here, and Adrian has also provided some examples of styling:
In addition, Adrian has written an algorithm for resolving which styles apply to a particular element (found here under Algorithm for calculating an element’s applied styles).
The work to date specifies the infrastructure for styling, but at the present time, the only actual style property that is defined in the specification is color. Adrian has created issue #283 to capture initial discussion about the style properties that should be added; as consensus emerges, we will then create separate issues to capture the specification of individual style properties. Adrian proposes that the next style property that we should fully specify should be for specification of the music font.
As previously discussed, Adrian also plans to start drawing out ideas for how to specify the differences between score and part layouts (issue #34). Work on this larger issue can proceed in parallel with considerations for specific style properties.
TPAC 2022 meeting
This year’s W3C TPAC will be taking place in Vancouver, Canada from 12-16 September 2022 as a hybrid event, mixing in-person and virtual attendees. We are considering requesting a slot in the schedule for Thursday 15 September 2022, so that our Community Group meeting for this year would take place at TPAC as it did last year. We have to submit our proposal within the next two weeks, so if you have any strong objections to our meeting taking place at TPAC or on this date, please post to the public-music-notation-contrib mailing list as soon as possible. We anticipate that we three co-chairs would be attending virtually rather than travelling to Vancouver, but if you would be interested in attending the conference in person, please also let us know via the mailing list.
We will finalise our decision at the next meeting of the co-chairs in two weeks’ time, so please provide your feedback as soon as possible.
The next co-chairs’ meeting is scheduled for Tuesday 24 May 2022.
At our last meeting we asked for feedback from the community concerning the proposed change to the styling proposal to unify the element and class attributes for the style element (pull request #282). The feedback we received was positive, so Adrian will proceed to merge this pull request shortly. Adrian will need to finalise the documentation for the new style element (largely based on Joe Berkovitz’s original proposal in issue #263) and write a few more examples, then this issue will be resolved.
After this is completed, Adrian will continue to investigate the errors Michael has reported with converting MusicXML with the MNX converter, and then attention will turn to issue #34, concerning differences between parts and scores.
The next co-chairs’ meeting will be on Tuesday 10 May 2022.
Pull request #282 concerning the proposals for styling (issue #263) continues to attract some good feedback. In particular, Samuel Bradshaw suggested that instead of using separate attributes for element and class, MNX could instead use a single selector attribute for the style element, using a very limited subset of the CSS syntax for selectors that are used to identify IDs and classes. Adrian is in favour of this change as it seems more elegant, so although it will require a reasonably large set of changes to the proposal it is still not too late. If any community group members have any thoughts on this change, please comment on the pull request.
Michael has sent some MusicXML files that cause the mnxconverter to throw errors when converting to MNX, and Adrian is also working on addressing these errors.
The next co-chairs’ meeting will be on Tuesday 26 April 2022.
The co-chairs would welcome some more feedback on pull request #282, which has as yet attracted surprisingly little engagement from the community. This is an important aspect of the MNX specification, and we want to be sure that the community agrees with the proposal before we merge the pull request. Even if you have no suggested changes to the proposal, indicating your agreement by a simple comment or using one of the supplied emoji buttons would be welcomed.
The next co-chairs’ meeting will be on Tuesday 12 April 2022.
It was recently announced that Musikmesse 2022, which had been scheduled for 29 April–1 May 2022, has been cancelled, and the B2B part of the fair has been cancelled permanently. The co-chairs are considering some alternative events and conferences that might possibly be a future home for our in-person meetings in Europe:
Open source:FOSDEM, normally in Brussels in February.
W3C:TPAC, which rotates around the world, and in 2022 is expected to be in Vancouver, Canada, and it’s not clear when it will next be in Europe.
We could also consider meeting at IRCAM in Paris, or at Steinberg’s headquarters in Hamburg.
We welcome any further suggestions of events, conferences or organisations that could host our in-person meetings, and feedback on whether any of the above would be preferable.
Adrian has created pull request #282 to cover the proposal for styling attributes in issue #263, and welcomes feedback. Adrian has written a synopsis in the pull request itself as an introduction, and invites the community to digest the pull request and provide further feedback.
Adrian will next turn his attention to developing a proposal for how to handle the differences between full scores and instrumental parts, for issue #34.
Daniel has started some initial work on SMuFL 1.5, with the intention of producing a new revision of the specification by the end of 2022. He has created a SMuFL 1.5 milestone on GitHub and has reviewed all of the existing open issues, assigning 30 of the 48 open issues to that milestone for consideration and potentially implementation. An updated set of labels has also been added, and these labels have been applied to the existing issues.
Daniel has also decided to use mdBook instead of GitBook to produce future versions of the specification, and the current editor’s draft is now using the new mdBook output. mdBook is more lightweight than GitBook, has a better author-test-publish workflow than GitBook, and produces output with a better user experience, including enhanced search.
One of the issues that we hope to address in the next revision is #214, to provide translations for the human-readable names in the glyphnames.json and ranges.json SMuFL metadata files. The co-chairs are currently evaluating a pair of online translation management tools (Transifex and POEditor), both of which provide a free service to open source projects.
We have also enabled the GitHub Discussions area for any questions about how to use SMuFL, announcements about any new software that implements SMuFL support, and so on. Please feel free to make use of this new discussion platform.
If you have any issues that you would like to be considered for inclusion in SMuFL 1.5, please ensure they have been raised on GitHub as soon as possible so that we can start to bring the scope of the new version into focus.
The next co-chairs’ meeting will be on Tuesday 29 March 2022.