2022 Community Group Meeting Minutes

As part of the W3C TPAC 2022 conference, the W3C Music Notation Community Group held an online meeting via Zoom on 15 September 2022. 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 a complete transcript is also 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 attending the meeting via Zoom:

• Michael Good, MakeMusic (co-chair)
• Adrian Holovaty, Soundslice (co-chair)
• Daniel Spreadbury, Steinberg (co-chair)
• Douglas Blumeyer
• Eric Carraway, percuss.io
• Michael Cuthbert, MIT
• Jim DeLaHunt
• Fabrizio Ferrari, Virtual Sheet Music
• Samuel Fuentés Fernandez, Universidad Politécnica de Madrid
• Dominik Hörnel, capella-software
• Reinhold Hoffman, Notation Software
• Markus Hübenthal, capella-software
• James Ingram
• Jeff Kellem, Slanted Hall
• Tristan Labelle
• Mingyu Lei
• Christina Noel, Musicnotes
• Alexander Plötz
• Klaus Rettinghuas, Enote
• Philip Rothman, NYC Music Services
• Jeremy Sawruk
• Dominique Vandenneucker, Arpege Music

Introduction to the Music Notation CG (2:16)

Michael Good began with an introduction to the work of the W3C Music Notation Community Group. This includes the very popular published standards, MusicXML and the Standard Music Font Layout (SMuFL), as well as the newer MNX project that is under development.

MNX update (7:30)

Adrian Holovaty provided an overview on recent MNX progress. We addressed several difficult architectural issues over the past year, including:

• The new concept of “layouts,” which allow music to be encoded in a single MNX file with multiple representations (e.g. full score, condensed score, individual parts). Each representation is called a score. Layouts contain the presentation information for a score, or for a system within a score.
• A “styles” infastructure, providing a way to apply presentation information to a subset of notation in the score. Inspired by CSS stylesheets, styling can be applied either globally to elements, or by classes that are specified within the musical data. Styles can be global to a document or specific to a score.
• How to represent notational differences between scores and parts (as opposed to the aforementioned layouts and styles). The first area we addressed is multimeasure rests, which are defined on a per-score basis within an MNX document. This should be able to serve as a model for other data that differs between scores and parts, such as enharmonic note spelling.

All these features work together to help separate presentation information from musical semantic information, a key requirement for many of the MNX use cases.

The MNX specification and “By Example” documents were both moved over to the group’s new documentation system in the past year, and some smaller specification issues were also addressed.

Jim DeLaHunt asked about preparing choral rehearsal scores that emphasize one voice part while de-emphasizing others—say by putting the singer’s part on one staff, and the remaining parts on a single combined staff with smaller notes—and what features would be used to achieve this. Layouts are the main feature that would be used here. This is an example of an MNX use case for digital score features that goes beyond what is available in printed scores.

Next steps with MNX are to:

• Finalize the list of V1 features, now that most of the outstanding major architectural issues have been addressed.
• Implement each remaining V1 feature using an example-first approach.
• Continue implementing the mnxconverter open-source utility for converting from MusicXML to MNX.

People can get involved by following the MNX issue tracker on GItHub. Posting opinions, even if it’s just a thumbs-up, is helpful. We also post updates on the Community Group blog, but most MNX conversation happens on GitHub.

SMuFL update (25:05)

Daniel Spreadbury provided an update on plans for SMuFL 1.5. While the new version will add a few dozen new symbols, the main focus is on improving font-specific metadata, especially regarding optional glyphs. This includes:

• Defining categories of optional glyphs (e.g. for different sizes or different historical periods)
• Allowing grouping of optional glyphs into sets
• Making it easier for applications to use, and present to the user, optional glyphs as alternates.

SMuFL 1.5 will also rework the definition of fonts used in text-based applications. It will move away from supporting simple music layout like the Bach font does, and instead support the simpler and nowadays much more common use cases of inserting individual musical symbols into text. As far as we know, Bravura Text is the only font that has ever implemented the more complex text font specifications.

We are also asking for translated human-readable descriptions for glyphs and ranges. Transifex provides a translation platform which is available for free to open-source projects like SMuFL, and that is where we have set up the translation project. We have the SMuFL 1.4 versions of ranges.json and glyphnames.json posted on this project and would be grateful for community contributions. Please don’t feel that you need to translate all 12,000 words to help out. Any translations or reviews of translations will help.

Another way to contribute is to follow the SMuFL GitHub issue tracker. The SMuFL 1.5 milestone indicates what is in scope. Look for issues with the label “Awaiting feedback” for those in particular need of review, often dealing with larger issues than just adding a well-documented glyph to a specific range.

Jim asked about the impact of the Unicode 15 release. Daniel answered that new Unicode releases generally do not affect SMuFL. All of SMuFL’s characters are in the Private Use Area in the Basic Multilingual Plane, which does not change between Unicode versions. While it is possible in the future that we might want to include some SMuFL ranges in Unicode proper, it is not currently in our plans, especially as more and more fonts and applications adopt the SMuFL standard.

Jim also asked about the use of OpenType variable font techniques in music notation fonts. OpenType variable fonts allow a single font to act like multiple fonts with continuous interpolation between different designs. Daniel answered that SMuFL tries to be as font-agnostic as possible. Even though most fonts these days are OpenType fonts, not all application contexts provide access to a wide range of OpenType APIs. There doesn’t seem to be anything that SMuFL needs to say about SMuFL variable fonts, aside from possibly adding some new information to the font-specific metadata file.

Jeff Kellem confirmed that there isn’t much, if anything, that SMuFL needs to do in order to define variable music notation fonts. However, no music notation applications are currently using those features. If they do in the future, OpenType metadata is probably sufficient, SMuFL probably would not need to add new font-specific metadata, but might want to provide recommendations about particular features to use.

Philip Rothman asked about the possibility of doing something better for chord symbols. Chord symbols work more like music notation, but applications treat them more like text, picking and choosing from text and music fonts and combining them in ways that are unique to each application. Could SMuFL provide a spec for chord symbols, perhaps using OpenType features, that would let a font specify how to mix the text and musical symbols together so that chords would look the same in any application?

Daniel replied that this is a huge area, having helped implement two of the systems that Philip referenced. The level of guidelines for chord symbols would be much more complex than current SMuFL guidelines, in part because it really involves 2D kerning and scaling. Also, would applications use this, given that each application already has its own complex way to display chord symbols? Relying on OpenType features could also limit how many applications could use this. The attraction of the idea is clear, but the complexity seems daunting—an order of magnitude more sophisticated than SMuFL’s current registration guidelines. It is an interesting idea to ponder when looking beyond SMuFL 1.5.

Jeff replied that equation rendering for math fonts might provide a model for this of work. There are kerning tables specific to the math use.

Klaus Rettinghaus asked about whether to report an issue to SMuFL or to Bravura if you do not know where the issue actually is. Daniel answered that the rule of thumb is that visual problems with a particular Bravura symbol should be reported to Bravura, and pretty much anything else reported to SMuFL. Daniel follows both repositories and can transfer issues back and forth, so please don’t let that uncertainty keep you from reporting issues.

Michael asked about adding other languages to the translation project beyond the five languages currently there (French, German, Italian, Japanese, Spanish). If you sign up to the Transifex project, you can specify which language you want to translate. So request a new language and Daniel will be happy to set it up.

Instrument data update (1:00:18)

Daniel reviewed 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. When we updated the charter earlier this year, we added this project to the scope of the Community Group.

We did have conversations with a few people who were interested in this project, but have not yet actually gotten started. The likely starting point will be to collect a list of use cases, like we did with MNX. We will need someone to volunteer to lead this project in order to make progress. This person need not be a group co-chair. If you are interested, please contact the co-chairs.

We would like to make some progress on this project by the time of next year’s meeting.

MusicXML update (1:06:02)

Michael provided a brief MusicXML update. Since MusicXML 4.0’s release in June 2021, we have been collecting issues for future versions on GItHub. There are no current plans for working on a version 4.1. We would first like a critical mass of issues, and our current preference would be to have at least a complete MNX 1.0 draft before starting a new MusicXML version.

However, with Michael’s retirement, these plans are all subject to change based on our next topic: leadership changes and the search for a new MusicXML specification editor and group co-chair.

Leadership changes (1:07:55)

Daniel discussed the Community Group’s upcoming leadership change. Michael will be retiring on 6 January 2023 and stepping down as Community Group co-chair at that time. We are looking for someone to serve both as Community Group co-chair and MusicXML specification editor.

We have been in touch with a few people already, but we don’t want to overlook anyone who might be interested. If you would like to be considered, please contact the co-chairs by Friday, 23 September 2022. Daniel has been leading the communication process for the search, so please feel free to email him directly. We will then be arranging times for the three current co-chairs to meet with each candidate. We need to be moving on in order to have a new co-chair and specification editor in place by early January.

What does it mean to be a co-chair and specification editor? The co-chairs meet for an hour every two weeks to discuss the current specifications and any other group-related issues, such as our annual meetings. Feedback on the specifications that are not your primary responsibility is also encouraged, as we discuss these issues at our co-chair meetings, especially around MNX.

The specification editor is responsible for writing and producing the new version of the MusicXML specification. This includes managing the GitHub backlog and issue list and determining scope for future releases, and coordinating the work involved in producing the specification. For MusicXML it is particularly important for the specification editor to be able to test changes, so access to an implementation that you can change is beneficial.

Jim asked if it is important that the new MusicXML specification editor also be a co-chair. Daniel answered that we believe that it is, in order to have equal representation for each of our three major specifications. Also, being a spec editor is much more work that being a co-chair, so if you’re a spec editor you might as well be a co-chair.

Jim followed up on that given that MNX is becoming more important while MusicXML is more static. There could be a separate co-chair who is not a spec editor to provide three perspectives in the co-chair meetings. How much work would actually be involved as a MusicXML spec editor, and does that person need to be in the top tier of Community Group leadership?

Daniel replied that it’s likely there will be new MusicXML release with more features, but we don’t know when that would be or what it would look like. However, we cannot escape that MusicXML is implemented in over 250 applications that are used by hundred of thousands, if not millions, of musicians on a daily basis. So even maintaining MusicXML in terms of improving documentation and other tasks could take a decent amount of work.

Planning for in-person meetings (1:22:22)

Daniel discussed possibilities for in-person meetings. We haven’t had one since April 2019 at Musikmesse, but Musikmesse is now permanently cancelled. NAMM was much smaller in 2022 than in previous years, though held in June rather than the usual January dates. Possible options include:

• TechChill, a startup-oriented conference in Riga held in February, suggested by Daniel Ray
• The NAMM show in Anaheim, being held in April 2023 before reverting to January dates in 2024
• TENOR, an academic conference tentatively planned for Boston in 2023
• The Music Encoding Conference, being held in Paderborn in September 2023 as a joint meeting with TEI
• Music Austria, perhaps the closest thing in Europe to Musikmesse, but held every two years so not until 2024

Another possibility is an organization’s offices, like Steinberg in Hamburg or IRCAM in Paris. But independent meetings outside of an event are tricky for getting permission or funding to travel unless you live nearby.

Daniel asked for people’s thoughts and suggestions on other possible events, and people’s opinions on in-person meetings in general.

Michael mentioned W3C TPAC in person as a possibility. It alternates between Asia, Europe, and the Americas, and also tends to have a higher registration fee than music events like Musikmesse and NAMM.

Christina Noel mentioned that NAMM would be easy for her to attend since Musicnotes regularly goes there. But she’s willing to show up in person whereever.

Jeff mentioned music librarian conferences or orchestrator conferences as a possibility. Daniel mentioned that for MOLA in particular, the technology industry is not really invited to that conference. Invitations tend to be one-off special guest appearances. Daniel wondered if other performing organizations might be possible, but groups like the Musicians Union don’t tend to have big shows any more.

Michael Cuthbert suggested a music notation meetup. Daniel mentioned that this provides a way around the standalone event issues with travel.

Daniel requested that if anyone has ideas for venues for in-person meetings, please let the co-chairs know.

Q&A (1:32:41)

Jeremy Sawruk asked about an event at ISMIR. Michael said he should have included it and overlooked it. This year it is in India, but 2023 has not been announced yet—it is typically announced at the previous year’s conference. It does move around a lot as an international conference.

Michael Cuthbert asked how W3C has been working as an umbrella organization. He has heard about the changes at W3C with MIT no longer being a hosting organization, and also ran into great problems trying to vote his approval for the MusicXML 4.0 specification.

Daniel answered yes, even though there is some wonkiness in voting and in joining / leaving the group. We get free infrastructure like the blog and GitHub account, as well as staff support. The biggest advantage could be the legal framework in place for developing these types of unencumbered, royalty-free standards.

Michael Good also answered yes, it’s been a fantastic home. It’s a better home than he expected, since he was concerned about the level of support at a free price level. But attending the CEO overview at TPAC this week showed the importance of Community Groups in terms of growing the W3C developer community, and making W3C the place where web standards happen. Community Groups get the W3C working on new things, often serving as feeders to W3C Recommendations. The number of developers associated with W3C has increased from 1,500 to 15,000 in the past 10 years. The importance of the community as an asset to W3C helps explain why we get better support than expected. He also thinks that W3C’s move from a consortium sponsored by four different organizations (including MIT) to a separate legal entity sounds like a good thing that will make W3C a stronger organization and thus be beneficial to us.

Adrian also answered yes, emphasizing the credibility that W3C provides to our work, especially for newcomers to the music notation world coming from a web developer background.

Jim mentioned that he would love to see seamless inter-conversion between MusicXML, MNX, and MEI, as well as a music notation diff tool to compare scores. Is there any obstacle to conducting that work under the auspices of the Community Group?

Adrian replied that his long-term vision for the mnxconverter is to support two-way conversions with multiple formats, including formats like MEI and abc. Tools like music diff are great things to experiment with in open-source implementations once MNX 1.0 is released. It’s not clear whether these would be produced in the Community Group or elsewhere, but is of great personal interest. We’re a ways away from that at this stage. Jeremy seconded Adrian’s point about general-purpose music notation tools, which is something he thinks could be developed within the context of MNX. Perhaps this could be a generalized plug-in interface, or music notation API.

Christina asked how far we think we actually are away from MNX V1. Adrian replied that it’s hard to say. Enharmonics and other score/part differences are the main remaining major piece, but then there are lots of details like articulations that need to be carried over. Finding time is an issue so more contributors, like Christina has been, are most welcome. Fortunately the list of big remaining architectural decisions has dwindled considerably in the past year or so.

Michael Cuthbert suggested that RomanText and other microformats might also be contributed to the Music Notation Community Group. We don’t have to necessarily work on things as big as MusicXML and MNX and SMuFL. Microformat spec editors probably don’t need to be co-chairs as the spec might be edited once every seven years or so when somebody finds a problem.

Meeting closed (1:52:22)

Michael Good concluded the meeting with information about how to join the Community Group and keep in touch with what is going on. He also thanked everyone for making the community such a great place for the continued maintenance and development of all these great music notation standard. He especially thanked Joe Berkovitz for his role in starting the Community Group. With his upcoming retirement, it feels really good to know that MusicXML and the other specs will have such capable leadership.