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 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.
The W3C Music Notation Community Group met online in a Zoom meeting on Thursday, 30 April 2020 between 2:00 pm and 4:00 pm UTC.
CG co-chairs Michael Good, Daniel Spreadbury, and Adrian Holovaty chaired the meeting, with 37 members of the CG and interested guests attending. The presentations from the meeting are posted at:
We recorded the meeting on Zoom and have posted it online at YouTube. Zoom provides an automatic transcription feature, so there is also a complete transcript available via closed captioning. The video starting times for each part of the meeting are included in the headings below.
Much of the group discussion happened in the Zoom chat window. We have incorporated highlights into these minutes, and you can also see the full chat log.
Attendees
Here are the meeting attendees in alphabetical order by organization:
Arshia Cont, Antescofo
Dominique Vandenneucker, Arpege / MakeMusic
Haipeng Hu, BrailleOrch / Open Braille Music
Dominik Hörnel, capella-software
Markus Hübenthal, capella-software
Christof Schardt, Columbus Soft
James Sutton, Dolphin Computing
James Ingram, self
Oleksil Sapov, Internationale Stiftung Mozarteum
Bonnie Janofsky, self
Jim DeLaHunt, Keyboard Philharmonic
Michael Good, MakeMusic
Jason Wick, MakeMusic
Michael Cuthbert, MIT
Peter Jonas, MuseScore / OpenScore
Martin Keary, MuseScore
Daniel Ray, MuseScore
Benjamin Bohl, The Music Encoding Initiative
Christina Noel, Musicnotes
Matan Daskal, Newzik
Marin Fauvel, Newzik
Kenzi Noike, self
Reinhold Hoffmann, Notation Software
Philip Rothman, NYC Music Services / Scoring Notes
James Opstad, self
Eric Carraway, percuss.io
Laurent Pugin, RISM
Jeremy Sawruk, self
Matt Briggs, Semitone (Komp)
Ben Spratling, Sing Accord
Jeff Kellem, Slanted Hall
Adrian Holovaty, Soundslice
Daniel Spreadbury, Steinberg
George Litterst, TimeWarp Technologies
Cyril Coutelier, Tutteo (Flat.io)
Roger Firman, UKAAF / MSA
Fabrizio Ferrari, Virtual Sheet Music
Introduction (0:22)
Michael welcomed everybody to the meeting. He outlined the rules of engagement for holding a meeting over Zoom, encouraging the participants to use the “raise hand” feature in the Participants list.
Michael introduced the W3C Music Notation Community Group and encouraged those in attendance to join the CG if they would like to contribute.
MusicXML 3.2 (5:17)
Michael introduced the goals for MusicXML 3.2, in particular to improve the support for parts and scores. The intent is to continue to work on both MusicXML and MNX in parallel, but to defer any use cases that cannot be solved without making major changes to MusicXML to the MNX effort.
Michael outlined the six main themes for the MusicXML 3.2 release, which can be seen in the V3.2 milestone in the GitHub repository, with a target completion date of the first quarter of 2021.
Improved Parts Support (9:04)
There are currently 8 issues in scope with the Parts label in the GitHub repository.
At the time of MusicXML’s inception 20 years ago there was no support in notation software for having the score and parts linked together or stored in the same file, and it was designed to model the experience of working with paper scores. Today things are very different, and in particular there is a specific need for Finale and SmartMusic to handle parts in a more sophisticated way. The approach that has been followed to date is to embed separate MusicXML files for each part in the MusicXML file, with a linking mechanism to correlate each MusicXML part in the score MusicXML file to each individual MusicXML part.
A goal is also to improve the interchange of part information even if you are exchanging only a single uncompressed MusicXML file rather than a compressed .mxl archive containing multiple MusicXML documents. MusicXML currently behaves poorly with concert pitch score documents, so one way in which this restriction can be eased is by providing information about the transposition of each part to be used when the score is viewed in transposed pitch (issue 279).
Michael had pointed out that one constraint on the design concerns trying to avoid particular patents. Jim DeLaHunt asked if these IP issues were enumerated anywhere, and Michael pointed out that the main issue concerns a patent held by Avid in the area of linked parts.
Machine Listening (16:15)
Machine listening applications include Metronaut and SmartMusic. These kinds of applications have different requirements and may need additional information that is not encoded notationally in the score. MusicXML provides the sound and play elements to provide supplemental information things that are not represented directly in the score, and the proposal is to add a new listen element, which would have a counterpart in a new player element, which would allow individual instruments to be grouped by player, handling divisi, and so on.
Michael outlined the different requirements that may exist for synchronization, including situations where the computer needs to wait for the performer, and those where the performer is expected to keep up with the computer.
Bob Hamblok had raised concerns about the amount of additional data that might be required to represent this new data intended for machine listening applications, but Michael sought to point out that the amount of data that will need to be encoded will not be significant.
Arshia Cont spoke to reassure other members that the additional data for synchronization etc. can be useful to applications that are interested in playback, as they can be used to improve humanisation of playback etc. Arshia expressed his strong support for this initiative in MusicXML 3.2.
Michael Cuthbert pointed out that “the sum total of all MusicXML ever generated might be about the same about of data as this 40-part video chat today is going to create, so from my perspective, let’s keep the data in our encoding!”
Tools (26:07)
Antescofo suggested that introducing an XML catalog would be helpful. If you’re validating a MusicXML file, the validation against the schema or DTD will go out to the web location, but XML catalogs make validation against a local copy of the schema or DTD much easier.
We cannot add an XML namespace to MusicXML without breaking compatibility with older MusicXML files, so the proposal is instead to adopt a standard namespace so that MusicXML can be combined with other XML vocabularies, when embedding MusicXML into other documents.
Michael spoke about some of the issues that exist with using code generation to create classes based on MusicXML, which have largely now got solutions. The goal is to document those solutions, and to ensure that any new features are not implemented in such a way as to be likely to introduce problems with code generation tools.
Another idea is to introduce XSLT stylesheets to automatically generate ID attributes for items in MusicXML.
It is also the intention to update the DTD and schema locations to reflect their current secure HTTPS locations.
Jim asked whether or not this tooling support might include additional features for producing a concise set of differences between two different scores, e.g. to facilitate the exchange of small differences like annotations. Michael pointed out that this might be more an application-level problem and not something that we would necessarily tackle as part of the format itself. Michael Cuthbert pointed out that this kind of diffing is very difficult – he has had two masters students working on the problem without completely solving it.
Gaps in Appearance (34:33)
Michael outlined a number of presentational items that cannot currently be described adequately in MusicXML, including some enclosure types, the appearance of measure numbering for multi-bar rests, and so on.
Percussion grids (staves with wider than normal spacing) cannot be easily represented in MusicXML, so Michael proposes some changes to help improve this.
Michael also proposes that it might be time to tackle some long-standing alignment issues, including the vertical positioning of rests and the horizontal extents of barlines.
Gaps in Playback (41:11)
Adding support for swing in the form of a ratio etc. rather than relying on the duration and type values for note elements work to define the difference between the printed and played values. Daniel Ray proposes that perhaps using a set of swing descriptions, rather than numerically.
To allow better support for doublings, it’s important to be able to change instrument for virtual instruments in the same way as changing MIDI instruments.
The sounds.xml file hasn’t been updated since MusicXML 3.0, despite the intention of defining it as a separate file in order to allow it to be updated on a faster cycle than MusicXML itself. But the time has come to add at least one more tin whistle sound, and potentially further sounds if needed. Michael invites proposals for any other sounds that are not currently covered.
Benjamin Bohl says: “In terms of performance parameters I’d like to point you to the “Music Performance Markup“ model for describing performance parameters: https://github.com/axelberndt/MPM”
Documentation (47:07)
Improving the MusicXML documentation is a never-ending task. Michael welcomes a volunteer to help improve the design of Roman numerals for harmonic analysis, and Michael Cuthbert stepped forward to take this on.
Michael also says that moving the existing documentation for MusicXML 3.0 to the W3C site is a goal, but it’s challenging because it was authored in a moribund version of a proprietary tool.
Postponed to MNX (50:37)
Issues that will require greatly expanding the semantics of MusicXML for text and lines are going to be deferred to MNX.
Next Steps (52:23)
Michael asked the group whether this seems like a reasonable scope for the new version. Michael is also inclined to give MusicXML 3.2 the version 4.0.
Benjamin Bohl suggested that we might follow semantic versioning, but Michael is not keen on this as he doesn’t feel this is especially appropriate for slow-moving formats like MusicXML.
Support for both 3.2 and 4.0 appeared to be roughly even among the attendees. Michael proposed that we would conclude this topic after the meeting, perhaps with a formal poll among CG members in due course. We did a “show of hands” and 4.0 came out ahead roughly 2:1.
Community Group Membership (57:17)
Michael once again reiterated that if you want to contribute to any of the CG’s projects, you need to join the group. If you represent a company working in the field of music software, it’s important that you join as a representative of your company.
SMuFL (1:01:38)
Daniel outlined the current state of SMuFL 1.4, which is not really any further forward than last year. He reiterated that issues are always welcome.
Michael Cuthbert introduced two issues concerning text SMuFL fonts. He pointed out that Bravura Text is very large because of the many combining glyphs for allowing symbols to be raised or lowered by up to 8 staff positions, and this makes the font less useful for subsetting, etc.
He also pointed out that the use of Bravura Text in user interfaces is difficult because the size of, say, a sharp relative to a treble clef means that showing them at the same point size would produce very different visual sizes. Daniel’s initial reaction was that using Bravura Text in a user interface is not necessarily an appropriate goal for text SMuFL fonts, but it’s perhaps something that we could tackle as a separate effort.
MNX (1:12:00)
Adrian introduced the MNX Common by Example page, showing that the focus has moved to building the specification around specific atomic examples rather than from the top down. When designing new features, we are now working “examples first” and coming up with analogous MusicXML code to help make it more illustrative.
Benjamin Bohl proposed adding MEI as a third column to the examples page, which Michael opposes on the grounds that we should perhaps keep focus on the formats currently maintained by the CG. Adrian agreed, and said that it’s important to keep the examples very focused for the time being.
James Ingram asked to what extent the specification can be trusted. Adrian said that the spec can be trusted, but it’s easier to understand if you look at the MNX Common by Example file.
Benjamin Bohl shared some resources that the MEI community have been working on to ease the interchange with MNX:
The Music Encoding Initiative (MEI) sees the need to better connect with the MNX community. Thus we did some work to support this. Namely providing a MEI Basic customization that fits the current development status of MNX and providing a converter for MNX to MEI.
Adrian announced that we have begun work on a tool to convert MusicXML to MNX, which was released via a new W3C repository on GitHub soon after the meeting ended.
Adrian expounded on why Python was chosen as the language. It’s popular, well-understood, and runs on every operating system. Benjamin Spratling expressed concern that it can’t run on iOS. Jim DeLaHunt and Michael pointed out that it should be possible to run the converter on a website and have an iOS app use a web service to provide conversion.
An eventual goal is to provide a production-ready two-way conversion between MusicXML and MNX. Two-way conversion will be useful to help drive adoption. It will also hopefully be possible to use it as a MusicXML “cleaner,” allowing you to ingest MusicXML and output MusicXML that uses a more consistent approach, making it easier to write MusicXML importers.
Adrian also explained the non-goals for the project, to keep it tightly focused on providing a conversion process and nothing else.
Laurent asked whether the converter provided a direct correspondence between classes and MNX elements, and Adrian confirmed that this is the case.
Peter Jonas asked why not use XSLT to provide the translation? Adrian’s hypothesis is that it’s either not possible or is possible but extremely difficult to perform the conversion using XSLT. Michael pointed out that XSLT’s strengths don’t really lie in this kind of large-scale conversion project.
Adrian reflected on his experience working on the converter before and said that he was happy to report that it feels good, and is a testament to the work done by Joe on the bones of the specification.
It is hoped that mnxconverter will help to grow understanding and appreciation for the core MNX concepts, and provides another open-source approach to MusicXML parsing.
Matt Briggs asked whether it might be possible to create XSDs directly using reflection from the Python code. Michael said that we have no XSD schema for MNX at the moment, but there will be a schema available in the future. Benjamin Bohl suggested using ODD as it can compile to XSD, RNG, and so on.
Should I Start Using MNX? (1:43:15)
Adrian said that it’s probably not yet time to start implementing MNX unless you want to be on the bleeding edge, but it’s a good idea to become more familiar with the core concepts.
MNX vs. MNX-Common (1:44:04)
Adrian provided a quick recap of the “MNX” name and how it was originally conceived as a kind of umbrella term to allow the packaging of many different types of music data. The group then talked about two different specific flavours, MNX-Common and MNX-Generic, but this is clumsy. So we propose instead renaming MNX-Common to simply MNX, and MNX-Generic to simply MGX.
Christina Noel points out that MNX-Common and MNX-Generic were names that were hard-fought and feels that renaming the formats again now is not the right time. Michael Cuthbert agreed.
Peter Jonas pointed out that people will abbreviate to MNX anyway, and this could cause confusion, and the kinds of practical issues that Adrian elucidated last year.
Jeremy Sawruk proposed perhaps keeping MNX-Generic but dropping “Common” from MNX.
James Sutton pointed out that there is at present very little in common between MNX-Common and MNX-Generic, and it’s unlikely that they’ll become more unified, so keeping the same name is itself confusing.
Start Implementation Milestone (1:53:03)
Adrian stated that the goal is to reach the milestone of the project being stable enough to be able to encourage developers to start implementing MNX-Common by the end of 2020.
Comments and Questions (1:54:30)
Daniel Ray asked whether MNX represents the best path forward. In the MIDI 2.0 specification, they have carved out some space for “notation over the wire”, and a couple of the companies in the MMA are, he says, working on this. He thinks this could be a common native format rather than a common interchange format. Michael responded, as he’s part of the Standard MIDI File 2.0 working group. The MMA community seems nowhere near as close as Daniel suggests, nor is it the best community to develop notation formats, because it doesn’t have the same concentration of expertise in the field as this W3C CG.
Benjamin Spratling asked if there were open source implementations of MusicXML that could render everywhere, such as using HTML or SVG? OpenSheetMusicDisplay, MuseScore, and Verovio were mentioned as possibilities for this, depending on just what you are looking for.
Jim DeLaHunt asked if there was already a place to discuss issues with scores as digital native documents such as formats, tools, and making editorial decisions in transcription projects, whether at the CG or elsewhere. Nobody could think of a place that was already doing this. The forums at notat.io might be the closest. W3C Community Groups don’t provide really great web tools for this type of discussion that is not related to specification and software development. Raising this as an issue on GitHub might attract some other ideas and suggestions from the community.
At the end of the meeting, 24 of the attendees had their cameras on for the group photo in the video thumbnail.
As part of the preparation for this week’s Community Group meeting, the co-chairs discussed the naming of MNX-Common and MNX-Generic. The naming is becoming more important with the project about to enter another pivotal phase.
The MNX naming scheme was proposed by former co-chair Joe Berkovitz when a key part of the plans was the notion that MNX would be a container format for a variety of symbolic music representation formats. Current co-chair Adrian pointed out the practical problems with this approach: developers and users alike would not know in advance whether a particular MNX file could be used with their application or contained the expected kind of data.
Consequently we agreed to go forward with MNX-Common and MNX-Generic, with the expectation that any further variants in the MNX family would have their own suffix. But this approach is somewhat clumsy, and the co-chairs will propose a new naming scheme at Thursday’s meeting.
MNX-Common will become simply MNX, while MNX-Generic will become MGX. There is no particular reason to define these abbreviations, but we can take the “MN” in “MNX” to stand for “Music Notation” and the “MG” in “MGX” to stand for “Music Generic”.
Community Group members will have an opportunity to respond to this proposal in Thursday’s Community Group meeting.
Community meeting preparation
The majority of the meeting was spent in reviewing the presentation planned for this Thursday’s Community Group meeting. If you wish to attend but have not yet signed up, there is still time, but you must sign up in advance so that you can be sent the Zoom meeting ID. Complete the sign-up form here.
Next meeting
The next meeting will be the Community Group meeting this Thursday, 30 April, and the next co-chair meeting will be on Tuesday 12 May.
Michael reported that we already have 30 people signed up for the forthcoming community group meeting, which will take place on Thursday 30 April 2020. If you’ve not yet signed up, please find full details here, including the sign-up form.
MusicXML 3.2 issues
Michael has been adding issues in preparation for the discussion about MusicXML 3.2, and after a brief discussion between the co-chairs in which it was agreed that these new issues should be in scope, he has added these issues to the MusicXML 3.2 milestone.
SMuFL 1.4 update
Daniel will give a short update on SMuFL progress in the online meeting in a couple of weeks. In the meantime he updated the co-chairs about some recent updates to Bravura, including retiring the SVG version of the font. There has also been a recent release of Bravura itself, bringing it to version 1.35.
Next meeting
The next co-chair meeting will be on Tuesday 28 April 2020.
With Musikmesse cancelled for 2020, we will move our annual meeting of the W3C Music Notation Community Group online this year. The meeting is scheduled for Thursday, 30 April at 2:00 pm UTC. This will be 7:00 am in San Francisco, 10:00 am in New York, 3:00 pm in London, 4:00 pm in Frankfurt, and 11:00 pm in Tokyo.
As usual we will plan for the meeting to last for 2 hours to allow plenty of time for discussion. The agenda will include:
MusicXML 3.2 kickoff
SMuFL update
MNX update
We will conduct the meeting using Zoom, the conferencing tool that we have used regularly for several years at MakeMusic. Zoom includes a feature to record meetings, so the meeting should be available afterwards for those who cannot attend live.
Please indicate your availability for the meeting by completing the signup form. It is possible that we may reschedule the meeting if we find that a large number of people cannot make the proposed date and time. Once you have signed up, we will send you a calendar invitation that includes the link to the meeting ID.
Thank you for joining us at this meeting from the safety of your own homes. We hope that all of you stay healthy in the midst of the current pandemic, and look forward to the time when we can meet in person once again.
Following the cancellation of Musikmesse 2020, we have now tentatively scheduled the virtual Community Group meeting for Thursday 30 April 2020 at 2pm UTC (3pm London / 4pm Berlin / 10am New York / 7am Los Angeles). The meeting will be held via Zoom.
If you are unable to attend at the chosen time, you can indicate another time that would be more convenient for you (though we will only consider rescheduling the meeting if a large number of attendees cannot make the original time). The meeting will be recorded and it will be possible to watch it again on demand after the event.
MusicXML 3.2 update
Michael has added a new issue #302 concerning a potential extension for piano pedaling without a specific end point. The co-chairs agreed that this should come into scope for MusicXML 3.2.
MNX-Common
Adrian has added a new section on rhythm (augmentation) dots to the MNX-Common by Example page. Adrian also had to take care of a small travis-ci issue related to the deployment of the MNX-Common by Example page.
Adrian has also created issue #174 concerning how repeat barlines and repeat endings should be encoded in MNX-Common. The co-chairs welcome feedback from the community about the proposed approach: Adrian has posed a number of specific questions and we welcome feedback on thos issues and any others arising.
Next meeting
The next co-chair meeting will be on Tuesday 14 April 2020.
Following the cancellation of Musikmesse 2020 due to the ongoing novel coronavirus outbreak, the co-chairs are actively looking into technological solutions for holding a virtual community group meeting. We anticipate that the meeting will take place a few weeks later than originally scheduled, possibly on Thursday 16 April 2020 at 5pm Berlin, 4pm London, 11am New York, 8am Los Angeles, and the co-chairs will provide more information on schedule and how to participate as soon as possible.
The topics for discussion at the meeting are planned to include a kick-off discussion for MusicXML 3.2, and status updates for SMuFL and the MNX-Common effort.
Next meeting
The next co-chair meeting is scheduled for Tuesday 31 March 2020.
Updated March 17: Messe Frankfurt has announced that Musikmesse 2020 is cancelled rather than postponed, and that the new dates for Musikmesse 2021 will be announced soon.
Today Messe Frankfurt announced that Musikmesse 2020 is postponed. No replacement dates have been announced yet. Thus we will not be having our meeting on 3 April 2020 as planned. We will provide further updates as we learn more.
The co-chairs discussed the potential agenda for the meeting. Michael proposes that the meeting could serve as the formal kick-off for the MusicXML 3.2 project, discussing both specific issues that are in scope, and whether or not the project should follow the same approach as MusicXML 3.1, i.e. to avoid introducing changes for structural issues being addressed in MNX-Common. Adrian will also provide an update on the MNX-Common project.
Daniel will unfortunately be unable to attend, because his employer Steinberg has instituted precautionary restrictions on business travel that will prevent him from traveling to Germany for Musikmesse. However, at the time of writing, both Michael and Adrian expect to be in attendance, unless Musikmesse itself is cancelled or postponed.
Messe Frankfurt has posted an advisory on its web site expressing its confidence that it has the necessary precautions in place to protect the safety of those in attendance.
The co-chairs will continue to closely monitor the situation and will update the community group if and when there is any further information provided by Messe Frankfurt.
Please let us know whether or not you plan to attend by filling out the Musikmesse meeting sign-up form. You may change your response after filling out the form as needed. This will help us in planning for the meeting.
Next meeting
The co-chairs will next meet on Tuesday 17 March 2020.