NAMM Meeting Minutes

Participants and potential participants in the W3C Music Notation Community Group met in Anaheim, California on January 23, 2016 during the annual NAMM show.

Ryan Sargent from MakeMusic photographed the attendees. From left to right they are:

• Daniel Spreadbury, Steinberg (co-chair)
• Evan Brooks
• Michael Good, MakeMusic (co-chair)
• Joe Berkovitz, Hal Leonard/Noteflight (co-chair)
• Jeremy Sawruk
• Martin Marris, Notecraft
• Joe Pearson, Avid Technology
• Kazuo Hikawa, Crimson Technology / AMEI
• Deryk Rachinski, CCLI

Michael Johnson from MakeMusic and Yasunobu Suzuki from Roland also attended, but left before the photo was taken at the end of the meeting.

The agenda for the meeting included discussions of:

• An introduction and background about the formation of the Community Group, led by Joe Berkovitz
• SMuFL 1.2 updates, led by Daniel Spreadbury
• MusicXML 3.1 updates, led by Michael Good
• A group discussion of what’s next after SMuFL 1.2 and MusicXML 3.1

Introduction and Background on the Community Group

Joe Berkovitz started the meeting with a brief introduction and background on the formation of the Community Group.

The World Wide Web Consortium (W3C) is an organization that creates specification, and can offer many resources to assist in the creation of specifications. The W3C also is the author of other specifications, many of which are relevant to music notation applications, such as CSS, HTML 5, the SVG graphics format, and Web Audio.

Moving development of MusicXML and SMuFL to a consortium provides an open playing field and open governance for developing support for additional use cases beyond MusicXML’s initial focus on exchange and archiving. It is great to have MakeMusic and Steinberg’s contributions of MusicXML and SMuFL, and Michael and Daniel’s continued participation as co-chairs. The consortium provides an opportunity to re-examine things and make things better for everyone.

The specifications from the W3C are produced by Working Groups and are called Recommendations. We are in a different path at the W3C called a Community Group. Community Groups have open membership and no membership cost. One does not need to be a W3C member to be a participant in a W3C Community Group. Community Group processes are more informal than Working Group processes. Whereas Working Groups produce Recommendations, Community Groups produce Community Group Reports.

Ideally the output of this Community Group will make a transition to a Working Group at some point. Costs are an important issue for the music notation community, and the W3C is working on more cost-effective methods of joining the consortium, such as single-specification membership.

Evan Brooks mentioned that it is brilliant to have both MusicXML and SMuFL in the Community Group as that provides critical mass for music notation standards. Jeremy Sawruk agreed, saying this was fantastic for developers.

SMuFL 1.2 Updates

Daniel Spreadbury discussed what is being planned for SMuFL (Standard Music Font Layout) 1.2. The major proposed updates are 4 to 5 dozen new characters, and some updates to the metadata layout for features like cutouts. These proposals are all in GitHub as issues with a v1.2 label. We will discuss the issues in GitHub and then proceed to update the repository. Anybody in the Community Group can submit a pull request on GitHub, but only the co-chairs can merge the pull requests into the mainline for either SMuFL or MusicXML.

We welcome all feedback on the specification for things that are not clear. Evan Brooks has already helped in this regard by pointing out inconsistencies between the SMuFL specification and the Bravura font that have been cleaned up in both SMuFL and Bravura.

Possible additions beyond SMuFL 1.2 include more dedicated support for tablature, and improving metadata to specify what glyphs are present in a font in an indirect way that is independent of changing font technology.

This was followed by a lot of discussion on building and using SMuFL fonts:

Font Creation. Martin Marris wants to create a new font and asked about how to create the SMuFL metadata. Daniel replied that there are scripts available for both FontLab and FontForge to assist with this. Both Daniel and Martin use FontLab. Daniel found that he needed to use Adobe Illustrator to get stem corrections correct and then bring that into FontLab.

Testing New SMuFL Fonts. Testing new SMuFL fonts is tricky since existing applications have incomplete support for SMuFL (at best) that don’t fully meet testing needs. Joe Berkovitz suggested that the group publish the HTML testbed for SMuFL that Noteflight developed earlier in the SMuFL process, which should help with testing.

SMuFL Font Profiles. SMuFL contains thousands of glyphs. It doesn’t make economic sense for all fonts to support all glyphs. Jeremy suggested some sort of “minimum viable profile” for SMuFL. This was discussed earlier in the SMuFL process and the decision at the time was not to provide a profile, but this could be revisited. Note that while SMuFL arranges glyphs into categories, the categories are not developed with profiling in mind. Infrequently used symbols are combined with frequently used symbols within a single category. Evan noted that having a minimum required profile would still not remove the need for an application to have some sort of backup in place in case the current font does not have a given character, but it might reduce the frequency of problems.

Families of Fonts. With older music technologies, fonts like Maestro and Opus had several different families with different name (e.g. Maestro Percussion, Opus Special) for different symbols. Martin asked if this was something that new fonts should consider doing. Daniel advised against breaking a SMuFL font into two or more parts, while recognizing that this does require using more modern font technologies such as OpenType or AAT. Larger fonts do increase the need for updates to the entire font when individual glyphs are changed, in which case a user would need to save an older version of the font for use with existing documents and projects in case the appearance changes. However, this can happen whether or not a font is split up.

Web Resources. There are still some open questions about how to best package SMuFL fonts as web resources.

SMuFL and MusicXML. Questions came up about a possible SMuFL namespace for MusicXML, and how integrating SMuFL more closely into MusicXML reflects the push and pull between the semantic and graphic roles in MusicXML. This led us into our next topic, a discussion of MusicXML 3.1.

MusicXML 3.1 Updates

Michael Good discussed what is planned for the updates in MusicXML 3.1, and the motivation for a MusicXML 3.1 release.

The discussion the group just started about the role of semantics and graphics in MusicXML is one of many structural issues with music notation markup that the group will want to consider in the future. However, the MusicXML community needs an update sooner than we will resolve these deeper issues. The focus is on bug fixes, minor features, and expanded symbol support.

The primary goal of the MusicXML 3.1 release is to keep interoperability alive right now at the same level as MusicXML 3.0 provides. In particular, with the upcoming release of more applications with SMuFL font support, we need support for more SMuFL glyphs.

Michael’s goal is to get a MusicXML 3.1 update out within the next few months. This is likely to still not have support for every single SMuFL glyph. It also doesn’t mean that each element that has a list of possible glyphs will support every possible variant in the sense of a MusicXML schema enumeration. This maybe happen in some situations, but in others, elements will be able to designate a specific SMuFL glyph in a semantics-free kind of way, referring to SMuFL unique name rather than a code point.

MusicXML 3.1 will also fix many documentation bugs. Those will likely be among the first issues addressed, after converting the MusicXML licensing language to the W3C Community Group licensing language.

Like SMuFL, MusicXML has moved to a Git repository on GitHub. Contributors need to join GitHub and follow the Git feature-branch and pull request workflow.

Evan suggested that MusicXML 3.1 should address the issue of whether the endpoints of grouping symbols (such as 8va octave-shift elements) are defined to be inclusive or exclusive of the last member. Michael responded that this was a good idea. The co-chairs encouraged Evan to join the community group as a participant, create a GitHub account, and add this issue to the MusicXML repository.

What’s Next After SMuFL 1.2 and MusicXML 3.1

Joe Berkovitz began the discussion of what’s next after the short-term SMuFL and MusicXML releases. As a group we need to know what is in scope and out of scope in order to make progress. Otherwise there can be endless raising of esoterica if there is no way for people to have a shared understanding of what is important and in scope, and what is not.

To this end, we are creating a music notation use case document. The initial draft is on the group Wiki. The document is organized by user roles. At this point we are trying to be as inclusive as possible in collecting user roles and user actions. Eventually we will need to decide what’s in and what’s out, but not yet. Collection is an important step in the process. Joe read several of the use cases from different user roles currently in the document to provide a flavor for the range of issues under consideration.

The group returned to the discussion of semantic and/or visual focus raised by Evan earlier. Joe mentioned that one example of a way to separate the visual from semantic is by using CSS, rather than the mix of elements and attributes that is currently in MusicXML 3.0. The use of CSS classes could remove a lot of redundant formatting information that is currently in MusicXML files. CSS media profiles and queries could help with responsive design for music notation.

As with web documents, not all formatting needs to follow a class in a style – one-off style attributes could be used in elements when needed. The types of formatting used would also likely be different than what CSS provides, such as for note positions. Jeremy suggested this could lead to an “MSS”, or music style sheet.

There are problems that CSS has not solved that are important to music notation, such as pagination. This is currently a big topic in the EPUB community. The W3C digital publishing group is looking at this – an instance of possible future collaboration between the Community Group and W3C Working Groups.

The current use case document has a technical requirement section that is similar to developer-specific use cases. One such case involves what happens when a user clicks on a note in a web application. A more hierarchical model that moves notes into a containing chord object (similar to a NoteRest in Sibelius ManuScript, or an entry in Finale) could make this type of interaction work more easily.

Currently applications have to map MusicXML into an interactive structure suitable for the application’s needs. Previous versions of MusicXML deliberately did not design for this use case, but times have changed. Applications may still need to do this mapping, but wouldn’t it be easier if the mapping were more natural? This is just one example of where the Community Group can take a fresh look at things to help move digital music notation standards forward.