2021 Community Group Meeting Minutes

As part of the W3C TPAC 2021 conference, the W3C Music Notation Community Group held a virtual meeting via Zoom on 28 October 2021, its first meeting for all group members since April 2020.

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.

The chat log is available here:

Participants

The following people attended the meeting via Zoom:

• Michael Good, MakeMusic (co-chair)
• Adrian Holovaty, Soundslice (co-chair)
• Daniel Spreadbury, Steinberg (co-chair)
• Douglas Blumeyer
• Chris Cianflone, MakeMusic
• Cyril Coutelier, Flat
• Jim DeLaHunt
• Roger Firman, Golden Chord
• Mark Green, MakeMusic
• Bob Hamblok
• Andrew Hankinson, Oxford University
• Marco Herrera-Rendon, MakeMusic
• Dominik Hörnel, capella-software
• Reinhold Hoffmann, Notation Software
• Kazuhiro Hoya, Japan Commercial Broadcasters Association
• James Ingram
• Peter Jonas, MuseScore
• Martin Keary, MuseScore
• Jeff Kellem, Slanted Hall
• Steve Lee, W3C
• Christina Noel, Musicnotes
• Cecilio Salmeron
• Jeremy Sawruk
• Rachel Yager

Introduction to the Music Notation CG (3:25)

Michael Good began with a short introduction to the work of the W3C Music Notation Community Group, and the pre-existing specifications that were brought under the auspices of the CG when it was formed in 2015, MusicXML and SMuFL.

Douglas Blumeyer asked about where the CG activity is happening. Christina Noel replied that if you want to get involved in the activities of the group, the majority of that activity is happening in the GitHub repositories for the main specifications.

Progress update since last meeting

Each of the co-chairs provided an update on the current projects undertaken by the Community Group.

MusicXML 4.0 (12:23)

Michael provided a brief overview of the new features and improvements in MusicXML 4.0, which was released in June 2021. Michael expressed his particular pleasure and pride in the revised MusicXML documentation, which has been wanted by the software development community for 20 years, and which will be of huge benefit to developers in the future. Many of the other improvements are very beneficial, particularly in handling scores written in concert pitch while retaining instrumental parts in transposed pitch. Machine listening features that will benefit applications like SmartMusic, Antescofo, Metronaut, etc. have also been a focus.

There are no current plans for MusicXML 4.1, but community group members are welcome to submit ideas and requirements by creating new issues in GitHub.

SMuFL 1.4 (20:06)

Daniel provided a brief update on the new version of SMuFL, version 1.4, that was completed in March 2021. No work on SMuFL 1.5 is currently ongoing, but it is hoped that work will begin in the first half of 2022. The focus for that release is not yet determined, but the expectation is that it will be focused on further enrichment of the font-specific metadata format, particularly with regard to management and meaning of optional glyphs.

Mark Green asked whether any consideration had been given to adding information to the font-specific metadata for the SMuFL version of specification a font conforms to. Daniel recommended that Mark raise this as an issue in the GitHub repository and that it would be considered for implementation in SMuFL 1.5.

Documentation generator for MusicXML and MNX (30:13)

Adrian talked about the reasons why he decided to build a new document generation tool to provide high-quality specification documentation for both MusicXML, which had been using documentation from an old version of Madcap Flare, and MNX, which had been using the Bikeshed specification generator.

Adrian built a new platform on top of the Django framework that allows you to run a locally-hosted web application to enter the structured data about the elements, attributes and data types in an XML-based specification, and then generate a complete web site for the specification.

The document generator system has a good deal of infrastructure around providing structured examples for the format being documented, so that all of the elements and attributes in the example are cross-linked to the relevant documentation.

Steve Lee asked whether he could get the URL for the example provided in the spec. Adrian explained that every element has its own permanent URL.

James Ingram asked whether it would be possible to add code folding to the examples. Adrian said that he thought this was a good idea, and could be implemented, with the only reservation that the highlighted markup for a particular example would probably need to be always expanded.

Ongoing work

MNX specification update (39:03)

Adrian talked about the ongoing work on the MNX specification, and in particular the large amount of work that went into the transition of the old Bikeshed-based spec into the new documentation tool.

Adrian outlined the benefits of MNX’s design, and in particular its desire to be highly semantic and with a clean separation between musical content and presentational or styling information. The format that is emerging is indeed strongly focused on semantics, and as a group we are navigating these sometimes tricky grey areas quite successfully.

The philosophy for developing MNX is to be example-driven, and pages like the comparison between MNX and MusicXML encoding are a strong focus for the development work. Michael stepped in to say that some of MNX’s design decisions make the format much more suitable for use as a native format for music notation applications than MusicXML, which is one of the strong benefits of the new format over MusicXML.

As a demonstration of the power of the semantic-driven approach being taken for MNX, Adrian showed a page of music in which music for multiple players are condensed down onto a single staff, something which is not easily possible in MusicXML, at least not taking a semantic approach. MNX, however, makes this possible by encoding the part elements (i.e. the music for each player) separately, and then there can be multiple separate score elements that are effectively a rendering of the semantic parts into a particular layout, determining the allocation of parts to staves. There are still some tension points to be resolved in this area, and Christina Noel and James Ingram appealed to other members of the community to join in this work.

The next steps with MNX are to put together the definitive list of remaining work for MNX 1.0 by assigning issues to the 1.0 milestone.

Jim DeLaHunt asked whether the MNX Converter project is one-way or two-way: currently it’s one-way (MusicXML to MNX), but Adrian expressed a willingness to make this two-way in future.

Steve Lee, as a new member to the group, asked about the plans for MNX, as to whether it is envisioned as a successor to MusicXML, and how we plan to get buy-in from software developers. Adrian replied that yes, it should ideally become the successor to MusicXML, and Christina Noel expressed that Musicnotes is already looking into supporting it. Adrian also expressed that he would draw upon Michael’s experience in building adoption for MusicXML.

Adrian also recommended that anybody interested in following the work on MNX should follow the blog and sign up for the public-music-notation-contrib mailing list.

Reinhold Hoffmann asked for an estimation of the realistic timeline for when MNX 1.0 might be ready. Adrian replied that there would probably be no down-side to starting implementation now, since the existing parts of the stable are considered to be stable. Reinhold clarified that he is interested in knowing when there will be sufficient momentum behind the format to cause multiple companies to decide to allocate resources to implementing the format. Adrian replied that this is really a difficult question to answer in general because every company’s priorities and level of resourcing are different. Michael suggested that, based on his experience with MusicXML, which took off once it reached version 1.0, that might be a good point to really determine the point at which it makes sense to start working on MNX implementations.

New possibilities for community group work

Instrument data (1:10:40)

Daniel talked about the idea, originally brought to the group by Daniel Ray of MuseScore, to build an open database of structured data about musical instruments for use in music notation software.

This idea was met with enthusiasm by the group, and several members immediately started sharing ideas and possible data sources to help get the project off the ground, including suggestions to reach out to musicologists, to the Musical Instrument Museums Online organisation, to refer to the existing taxonomy of more than 1000 instruments provided by Musicbrainz, and more. Mark Green suggested that it would be great to be able to include pictures (perhaps icons, photos, line drawings) of each instrument, and that localisation (of names, playing techniques, etc.) could also be valuable.

The co-chairs agreed that they will discuss this proposal some more, do some further research, and report back to the community group.

Non-Western music notation (1:27:31)

The group is not restricted by charter to focus purely on Western music notation, but the co-chairs feel that the current community group members don’t possess the necessary expertise to be able to develop formats for non-Western notation formats.

James Ingram says that he feels that once MNX 1.0 is complete, we may well find that support for some other notations, such as Asian notation systems, are reasonably close to Western tablature, and that the parallels between these notations might mean that some of the work has been done. Michael pointed out that the group’s work is guided by need and demand expressed by the group, so we do not necessarily have a strong long-term plan that already takes in these notations, but we remain open to the possibility of working on it in future if the demand emerges.

Updating the group charter (1:33:09)

Michael outlined the current state of the Community Group charter, which has not been significantly updated since the inception of the group in 2015. As the work on MNX has developed, some of the existing information in the charter has become outdated, and the co-chairs propose revising it.

Peter Jonas expressed surprise that the charter is sufficiently focused that it could go out of date. Michael explained that the original charter was drafted by original co-chair Joe Berkovitz, and that he had brought his experience as chair of the W3C Web Audio Working Group to bear on the process of drafting the charter. Michael pointed out that it’s common for both community and working groups to go through a process of re-chartering.

Michael has volunteered to take the lead on revising the charter and will report back to the group in due course.

Planning for in-person meetings (1:38:01)

Michael outlined the next possibilities for when we might be able to get together again in person, with the proposal that we would resume in-person meetings along with Zoom meetings. Spring 2022 provides four strong possibilities for in-person events:

• Musikmesse, Frankfurt, Germany (29 April-1 May 2022)
• The NAMM Show, Anaheim, CA (3-5 June 2022)
• TENOR Conference, Marseille, France (9-11 May 2022)
• Music Encoding Conference, Halifax, Canada (19-22 May 2022)

These events represent a balance between industry events and academic conferences, and Michael asked for feedback from the group about any preferences.

Mark Green asked whether it is typically possible to have virtual attendance at these in-person meetings, and Michael explained that this is not usually the case because the network facilities at these kinds of events tend not to be too good.

Jim DeLaHunt expressed his desire to see stronger cooperation between the W3C Music Notation Community Group and the MEI community, and perhaps setting up a meeting at the Music Encoding Conference would be a good opportunity to do that.

Q&A (1:47:05)

Jim DeLaHunt asked about converters between MNX and MEI, and wondered whether it might be possible to include MEI in the MNX by Example page. Michael cautioned that since there are hundreds of existing formats out there, and we might not be able to do a great job of managing examples in lots of other formats, and proposed that we in the community group ought to focus on our own formats. Adrian agreed that it would certainly be good to see the MNX Converter project become more powerful.

Meeting closed (1:52:01)

Michael closed the meeting by thanking everybody for their participation and provided links to how to join the group for any participants who are not already members of the group, and how to follow the specific GitHub repositories for each of the active projects.