W3C home > Mailing lists > Public > public-music-notation@w3.org > January 2016

NAMM Meeting Minutes [via Music Notation Community Group]

From: W3C Community Development Team <team-community-process@w3.org>
Date: Thu, 28 Jan 2016 00:01:52 +0000
To: public-music-notation@w3.org
Message-ID: <8445be32141c8a1b713a492b5d62787e@www.w3.org>
Participants and potential participants in the W3C Music Notation Community
Group met in Anaheim, California on January 23, 2016 during the annual NAMM

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

	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

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
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.


This post sent on Music Notation Community Group

'NAMM Meeting Minutes'


Learn more about the Music Notation Community Group: 

Received on Thursday, 28 January 2016 00:01:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 28 January 2016 00:01:57 UTC