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 initial task of the Community Group is to maintain and update the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle new use cases and technologies, including greater use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications.
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.
We have so far only had one comment on pull request #158, concerning a request to be more precise about the effect the octave-shift element has on both written and sounding pitch. It can be argued that the direction of the octave-shift could go either way, and so the co-chairs have decided to go with the same direction used in MusicXML. We think it might be worth having a separate discussion of the direction of the octave-shift in the spec. We will remove the description “true pitch value” to avoid any ambiguity about the effect on the written and sounding pitch. We are not going to revisit the more general definition of pitch for MNX-Common in connection with this pull request, though we do not rule it out for the future.
Adrian will make a few last changes to the pull request, and Michael and Daniel will review before the pull request is merged.
Spanning directions
Adrian is still working on more definitions for spanning directions for inclusion in the MNX-Common specification and the MNX-Common by Example page, which he hopes to have working soon.
MusicXML 3.2 update
Michael has added issue #293 to cover the requirement of describing changes in sound for virtual instruments. There are currently 28 issues in the MusicXML 3.2 milestone for consideration, and sorted into general categories of issues to work on next.
SMuFL 1.4 update
Daniel has not been able to devote any time to SMuFL 1.4 recently in the run-up to his recent product release but still anticipates being able to complete the work required for SMuFL 1.4 before the end of the calendar year.
Next meeting
The next meeting of the co-chairs is scheduled for September 24, 2019.
Adrian has been working on how octave shifts should be handled in MNX-Common, and has prepared a pull request #158 to address issue #111, which covers both the specification for and examples of the proposed octave-shift element. The co-chairs welcome feedback from the community about this new specification element. You can view the updated MNX-Common by Example file without checking out the branch here.
If you have any comments about this proposed change, please leave a comment in the pull request.
Adrian plans to continue work on spanning elements since he has now got a good feel of the issues these notations present, which will address issue #114 among others. He also plans to add a further example for the octave-shift element that applies only to a single voice or sequence.
MusicXML 3.2 and SMuFL 1.4
Michael and Daniel did not have any updates on the MusicXML 3.2 or SMuFL 1.4 projects for this meeting.
Next meeting
The next co-chair meeting will be on Tuesday 10 September.
Adrian has added a section on time signatures to the MNX-Common by Example page to illustrate the approach MNX-Common takes to time signatures, showing how time signatures are shown in the global element. The co-chairs discussed whether or not we should include the optional index attribute to each measure element that makes the bar number explicit, but decided to keep it as simple as possible for the purposes of this example.
The co-chairs discussed the issue of multi-metric music, which requires multiple global elements and the assigning of specific parts to the time signatures in each global element. There was also further discussion of whether index should be compulsory, which would enable a sparse representation of the global element, i.e. only including those measure elements in which there is a change of time signature, but this would require making index compulsory and it was decided not to revisit this prior decision again now.
Octave lines
Adrian is next going to look at giving examples of octave lines in MusicXML. Octave lines are an example of a spanning element, which appear either in the directions attribute of a measure element (if they apply to all voices) or of a sequence attribute (if they apply to a specific voice). We need to be clear about the end attribute and whether or not the note or event at that position is transposed by the octave line.
Adrian will work up an example for discussion and then move to adding octave lines to the spec. This will be relevant to issue #111.
MusicXML 3.2 and SMuFL 1.4 update
There was no discussion of MusicXML 3.2 or SMuFL 1.4 in this meeting.
Next meeting
The next co-chair meeting will be on 27 August 2019.
The MNX-Common and MNX-Generic specs have now been split and the pull request merged back to the master branch. The MNX-Common by Example page is also now part of the main MNX-Common repository and is linked to from the main page. This closes issue #98.
Issues under Active Review
Next on Adrian’s list is to pick one of the issues currently under Active Review and to flesh out a proposal by adding more information to the MNX-Common by Example page.
MusicXML 3.2 update
Michael has not made any specific progress on the MusicXML 3.2 specification issues since the last meeting.
SMuFL 1.4 update
Daniel has not made any specific progress on the SMuFL 1.4 issues since the last meeting.
Next meeting
The co-chairs will next meet on Tuesday 13 August 2019.
Adrian’s colleague Edward has made a responsive design for the MNX-Common by Example page, which looks good. The next steps are to merge this page to the MNX repository, and then to expand with further examples.
Splitting MNX-Common and MNX-Generic
Adrian didn’t create a pull request for splitting MNX-Common and MNX-Generic, but has now done so: pull request #157 exists to do this. We’ll give the community a week for any feedback on the pull request before we merge it.
DAISY Braille music working group
Haipeng Hu, representing the DAISY Braille music working group, has joined the community group and has raised a couple of new issues in the MNX repository, #155 and #156. The co-chairs have triaged the issues and assigned them to the MNX-Common v1.0 milestone. We welcome any feedback from the community on the requirements expressed in these two issues.
Michael said that he will also consider and respond to Haipeng’s issue #286 in the MusicXML repository in due course.
MNX-Common issues under active review
The co-chairs also discussed the issues under active review in the MNX-Common repository. All of them are currently waiting for Adrian’s proposals in response to community feedback on the issues of layouts and and he proposes that he will fold those proposals into the MNX-Common by Example page in due course.
Next meeting
The next meeting of the co-chairs will be on Tuesday 30 July 2019.
Daniel and Michael have reviewed Adrian’s proposal branch for splitting the MNX spec into separate MNX-Common and MNX-Generic specs for issue 98. Adrian will incorporate this feedback and then create a pull request for community review.
MNX-Common by example
Adrian has a designer working on the prototype MNX-Common by example page. Once this design work is done, more examples will be added and the page will move into the MNX repository at GitHub.
Next meeting
Due to vacations, the next co-chair meeting is scheduled for Tuesday, 16 July.
Following our last meeting, Michael worked through the issues submitted by the DAISY Braille music working group and sent a detailed response to project coordinator Sarah Morley Wilkins, Matthias Leopold, and Haipeng Hu. We are now waiting on a formal response from the DAISY group.
Splitting MNX-Common and MNX-Generic specs
Adrian has created a new branch where the changes to split the MNX-Common and MNX-Generic specifications are now in progress. Michael and Daniel will review the newly-split specifications, and once the co-chairs agree Adrian will proceed with a pull request for community review.
MNX-Common by example
When Adrian was working on splitting the MNX-Common and MNX-Generic specs, he came to the realisation that no developer would really be able to plough through the spec and clearly understand the differences between the well-understood MusicXML format and the new MNX-Common, so he started working on a page that shows a number of examples encoded in both MusicXML and MNX-Common, to provide simple illustrations of the differences. This is at a very early stage, but Adrian wanted to seek consensus from Michael and Daniel about whether this is a good approach. Michael and Daniel agree enthusiastically that this is a very valuable approach.
Adrian wonders whether we could even use this approach as a means of coming up with concrete syntactic proposals to address issues, so that the process would be to produce a worked example before creating a pull request on the specification. The goal would be to encourage wider participation by lowering the barrier to entry for members of the community to be able to discuss concrete examples. Michael and Daniel agreed that this would be a great approach.
Adrian will look into integrating the examples into the main MNX repository and do some reorganisation of the code to allow easier expansion. Adrian will also add some further examples to the current page, starting with examples that encode the recent decisions on sounding versus written pitch. In order to do this, we’ll need to address issue #111 and specify the way transposition will be encoded. Michael proposes we should follow the pattern suggested by the MusicXML transpose element, but use more attributes rather than separate child elements. Adrian will put together an initial proposal of how this might look.
Next meeting
The next meeting is scheduled for Tuesday 18 June.
Clarifying effect of octave lines on written pitch
The co-chairs agreed that pull request #152 is ready to merge in. Consensus is that octave lines do have an effect on the way the pitch is encoded, so if you have a middle C (which would in Scientific pitch notation be C4) with an 8va octave line written above it, it will be encoded as C5, i.e. transposed up by one octave. This also closes issue #4.
Realisations and layouts
It’s still on Adrian’s to-do list to move any remaining relevant comments from issue #138 onto issues #34 and issues #57. This is currently the second item on Adrian’s priority list.
Splitting MNX-Common and MNX-Generic
Adrian has been in touch with Joe and has completed the transition of the back-end process for automatically compiling the Bikeshed file into the specification from travis-ci.org to travis-ci.com, and has added a Contributing document to capture the details of these processes.
Adrian is going to add further detail to the document to clarify the process for dealing with incoming issues, which is in brief summary:
Any CG member can raise an issue.
Once the co-chairs have discussed it, it will get assigned to a milestone reflecting the current understanding of the issue’s priority.
The issues that are currently being discussed with a view to closing them and creating pull requests to add to the spec are tagged with the Active Review tag.
In theory, no issues will be worked on that are neither assigned to the V1 milestone or have the Active Review tag.
The co-chairs agreed that we should not split the MNX repository into two separate ones for MNX-Common and MNX-Generic, but rather we will have two Bikeshed files, one for each specification. This is the highest item on Adrian’s list.
DAISY Braille music group
Daniel reported that he today attended a meeting of the UKAAF Music Subject Area working group and the issue of the DAISY Braille music group’s collected requests for MusicXML came up. Daniel asked Michael on behalf of the UKAAF group to review the collected list of MusicXML requirements from the DAISY group and indicate to them which are already supported in MusicXML, which are out of scope for MusicXML and should be created as issues for MNX, and which could be added and considered for MusicXML 3.2.
SMuFL status
Daniel reported that he’s been working on tooling for SMuFL and is nearly at the point where he can create a new release of Bravura to match SMuFL 1.3 that addresses some outstanding issues with the metadata file for the font. Once that is done, he plans to start working on the first issues in the SMuFL 1.4 milestone.
MusicXML 3.2 status
Michael is planning to have some discussions with other developers to determine whether some of the issues that are being considered for the milestone are of broader interest than just to MakeMusic.
Michael expects this process to take another few weeks, and once that is complete he will start the process of assigning issues to the active milestone and create the first pull request to start the process.
Following some confusion with pull requests on the MNX repository, Adrian has been discussing with Joe how we should handle the branches on the MNX repository. Joe originally set up a Travis CI job on the master branch to automatically run Bikeshed on the files and push the changes to the gh-pages branch automatically. Joe suggested that we maintain his automatic process until Adrian can set up a corresponding set of automated steps for his own GitHub user. The issue is complicated by a new release of Travis CI since the time Joe originally set things up on GitHub. Adrian is in touch with GitHub and Travis CI about this.
The upshot is: all MNX commits, pull requests, etc. should be made on master, and these will all be automatically moved to gh-pages.
Adrian plans to write a CONTRIBUTING Markdown readme to add to the MNX repository. Once this is done, we will add corresponding versions of this file to the other two repositories.
Note that in the MusicXML and SMuFL repositories, commits are currently made on the gh-pages branch because there are no automated travis-ci processes in place on those repositories.
Splitting MNX-Common and MNX-Generic
The reason Adrian has not yet split the MNX-Common and MNX-Generic specifications is that the automated GitHub process for deploying the specification is hardwired to produce a single Bikeshed-based specification. Once the infrastructure changes above are complete we’ll get this split completed. Adrian has updated #98 to this effect.
Written vs. sounding pitch pull request
Adrian merged pull request #148 and the co-chairs discussed the process for reviewing pull requests. We reaffirmed that there is no specific time window for reviewing pull requests, and the co-chairs assume that if there is no dissent from members of the CG within a few days of the pull request being proposed, this will be taken as assent and the pull request will be merged.
Octave lines and sounding pitch
Adrian requested that Michael and Daniel review pull request #152 so that the co-chairs can come to a consensus on how or whether octave lines affect sounding pitch. Adrian has closed issue #4, but Michael suggested that we might consider reopening #4 until pull request #152 is settled.
Participation of co-chairs in issue discussion
One member of the community group contacted the co-chairs privately expressing frustration that proposed pull requests went unreviewed and uncommented by the co-chairs for an extended period of time. The co-chairs agreed that we need to do a better job of keeping on top of the comment threads in issues and review pull requests in a more timely fashion.
Realizations and layouts issue
Michael reminded Adrian that following our meeting at Musikmesse a few weeks ago, the plan is to close issue #138, but not until moving or referencing the comments into other relevant issues. Adrian agreed to undertake this so that issue #138 can be closed.
Discussion of #4. Adrian will post a comment saying that we are going to encode written pitch. He’ll follow it up with a pull request to change the spec to fill that part in. Initial pull request will clarify that we will encode written pitch rather than sounding pitch. We will also add definitions for written pitch and sounding pitch to the specification.
Some discussion about whether “written pitch” includes octave transposition (e.g. from octave lines or clefs with octaves indicated). Michael proposed that we should use the same approach as MusicXML, i.e. to include the totality of octave transpositions. Daniel and Adrian were unsure about this, since on its face it goes against the views expressed in the meeting by developers that they want the pitch encoded to match the displayed page, but Michael thinks we should do what MusicXML does and see whether there are objections.
Michael to see whether there is a good definition of written vs. sounding pitch in the MusicXML schemas or tutorial.
Discussion of #138. Adrian will post the same comment as in issue #4. We propose to then close this issue after bringing the relevant parts of Joe’s original proposal for realisations and layouts to the other issues, e.g. #34 for differences between full scores and parts, and issue #57 for system/page flow.
Following on from the pull request, Adrian will review Christina Noel’s proposal for how pitch might be encoded and consider whether or not this could be the basis of the approach.
MusicXML 3.2
We discussed how we should handle additional issues for MusicXML 3.2, including Cyril’s proposal for handling swing, and whether Michael should bring those issues into scope for the next release. We agreed that if Michael is happy to handle the specification duties, he can add them to the milestone without heavyweight co-chair review.
Adrian expressed concern that the approach suggested in #283 is possibly not the most semantic approach, and could break display and playback into separate elements. Michael believes these can indeed be combined in one element and address Adrian’s concern.
We discussed what to do with issues in the MusicXML repository that we have agreed to handle in MNX-Common. Michael will link them to an existing or new issue in the MNX repository and then close the issues in the MusicXML repository.
In the next week or so, Michael plans to put together the first pull requests for MusicXML 3.2, e.g. upping the version number and switching back to the Contributors License Agreement (CLA) for the development period, etc.
The next co-chair meeting will be on 30 April 2019.
