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.
For the past 3 years we have had a MusicXML community meeting at the Musikmesse fair in Frankfurt. This year we will have another meeting: the first meeting of the W3C Music Notation Community Group in Europe.
The meeting will be held on Friday, April 8 from 2:30 pm to 5:30 pm at the Logos/Genius conference room in Hall 9.1. As in past years, we plan to have a 2-hour meeting followed by a 1-hour reception sponsored by Newzik.
Our proposed agenda is to discuss the group’s progress on MusicXML 3.1 and SMuFL 1.2, and review the notation use cases that we expect to guide the group’s future work. We welcome your suggestions on changes or additions to this agenda.
Please sign up on our Google form at http://bit.ly/1U1SUIP if you plan to attend the meeting. This will help ensure that we have enough room and refreshments for everyone.
You will need a Musikmesse ticket to attend the meeting. These cost 25 euros and are available online at www.musikmesse.com.
We look forward to seeing you in Frankfurt!
Best regards,
Michael Good, Daniel Spreadbury, and Joe Berkovitz
W3C Music Notation Community Group co-chairs
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.
This month we plan to begin working on MusicXML 3.1, a short-term update to the MusicXML format to add greater coverage of musical symbols, along with targeted bug fixes and feature enhancements. We will also start work on SMuFL 1.2, a short-term update to the SMuFL standard.
We will be using the W3C’s MusicXML and SMuFL repositories on GitHub as the focus point for this work. If you do not already have an account on GitHub, please sign up for a free account at https://github.com. This will let you fully participate in the discussions. Once you sign up, it would be great if you could enter your GitHub ID and a brief summary of your music notation interests at the group’s Wiki page for contributors.
We already have an initial collection of MusicXML 3.1 issues at the MusicXML GitHub repository, and an initial collection of SMuFL 1.2 issues at the SMuFL GitHub repository. For each issue, we plan to have discussion of proposed solutions on the GitHub issue thread. Once the group comes to agreement, the changes will be made and reviewed on GitHub using standard Git processes.
If you have used Git before, this will likely be familiar. If not, the terminology may be new, but the ideas are pretty simple. We will be using Git’s feature branch workflow. Each issue will be worked on in its own named “feature branch” that branches off of the main GitHub branch. That main branch is called gh-pages in the W3C repositories. The feature branches will have names related to the issues.
Once the work for each issue is completed, there will be a request to pull the feature branch into the main gh-pages branch. This pull request serves as an opportunity for anybody following the issue to review the solution and propose changes. Once the group reaches agreement on the review, the changes will be merged from the feature branch into the main branch.
The main gh-pages branch in each repository will always reflect the latest reviewed, working version of the MusicXML schemas and the SMuFL specification and metadata files, respectively. The feature branches will be used for work in progress.
We have set up the Git repositories and the contributors mailing list so that the mailing list will get notifications of new issues, pull requests, and merges. This will only be part of the work going on at GitHub. The best way to follow and participate in the work is to “watch” the MusicXML and/or SMuFL repository once you have a GitHub account.
Git and GitHub may seem a little complicated the first time you use them. However they have become very popular for open source software development projects, including W3C projects like those at the Audio Working Group. Git and GitHub provides structure and transparency for software projects so you can always see what changes were made, who made the changes, when the changes were made, and why they were made.
We look forward to getting to work on the first W3C Music Notation Community Group updates for these important standards. Please let us know if you have questions about the work process. In the meantime, work will also continue on the use cases for a longer-term music notation format standard. See you on GitHub!
Happy New Year everyone! We are happy to announce that thanks to the work of Joe Berkovitz and NAMM staff, we will be having a W3C Music Notation Community Group meeting during the upcoming NAMM Show in Anaheim, California.
The meeting will be on Saturday, January 23 from 10:30 am to 12:00 noon in the Hilton Oceanside room. The agenda will include:
Community Group status update
Use case document discussion
MusicXML 3.1 updates
SMuFL 1.2 updates
Please let us know if you have suggestions for additional agenda topics.
Since the meeting is in the Hilton rather than the Anaheim Convention Center, you do not need to be registered for the NAMM show in order to attend the meeting.
We apologize for the short notice about the meeting. This was our first time working with NAMM staff regarding a W3C music notation event, so we have been learning as we go.
The room holds 30 people. We expect that will be sufficient given the short notice and the attendance at the NAMM MusicXML meeting in 2012. For planning purposes it would be helpful if you could let us know if you plan to attend. Feel free to send an email to Michael or to respond on the blog or mailing list.
For those who can’t make it to NAMM, we do hope to have a meeting at Musikmesse in Frankfurt this April, as we have done with the MusicXML community the past three years. We hope to provide more advance notice for that event.
We look forward to seeing many of you at this meeting!
2015 has been a major year for music notation standards with the formation of the W3C Music Notation Community Group. We are now at 222 members, making this the fifth largest community group at the W3C. Thanks to everybody for your interest and participation!
We recently started work on a music notation use cases document. This is on the Music Notation Community Group Wiki, and participants in the Community Group may edit it.
There are a lot of use cases in this document already. The two things we need are more complete descriptions for the existing use cases, and coverage for any use cases we may not have included yet.
We think it is best if people edit the use cases who are either in the role described by the use case, or are implementing solutions for people in that use case. For some roles this is pretty easy. Lots of members of this list are performers, and composers, arrangers, teachers, and students are also easy to find.
Some roles are more specialized, though. The use cases for musicologists, for instance, do not have any descriptions yet. The use cases associated with education, accessibility, and convergence with web and Epub technologies are also missing descriptions. If you are in one of these roles, or supporting people in these roles, we especially welcome your contributions to describing the use cases in more detail. Our headlines and one-paragraph descriptions are a starting point, but more detail will be needed to have these use cases are addressed effectively in the future.
This use case work is a first step toward an updated music notation format that builds on the success of MusicXML 3.0 for music document interchange and expands it to new uses. In the meantime, though, both MusicXML and SMuFL have some short-term needs that we want to start addressing later this month or in early January. These will be MusicXML 3.1 and SMuFL 1.2 updates.
MusicXML 3.1 will be focused on adding greater coverage for musical symbols, along with targeted bug fixes and feature enhancements. The goal is to maintain and improve MusicXML 3.0’s high level of document interoperability, without distracting from the longer-term work of the community group. You can see the current list of MusicXML 3.1 issues in the MusicXML GitHub repository.
Similarly, SMuFL 1.2 adds coverage for more musical symbols, and addresses other issues that have been raised by the SMuFL community over the past several months. You can see the current list of SMuFL 1.2 issues in the SMuFL GitHub repository.
We have added integration of the GitHub repositories into the public-music-notation-contrib mailing list so that group contributors will be notified of progress as the MusicXML 3.1 and SMuFL 1.2 issues are worked through in GitHub.
Thank you again for all your interest in this group. 2015 has been a year of transition and new beginnings for music notation standards. We look forward to 2016 when we expect the group to deliver its first updates to the MusicXML and SMuFL formats, and to start more extensive work on an updated web music notation format for the future.
Michael Good, Joe Berkovitz, and Daniel Spreadbury
W3C Music Notation Community Group Co-Chairs
Thanks to everyone for your thoughtful discussion of the agenda for the Music Notation Community Group. We have posted a summary of the discussion on the CG Wiki at https://www.w3.org/community/music-notation/wiki/Agenda_Discussion. In this post, the co-chairs would like to bring this discussion back to its effect on the short-term and long-term agenda of the group.
Our initial proposal for an agenda contained four short-term and three long-term projects:
Short Term:
Document music notation use cases
Build an initial MusicXML specification
Add support for use of SMuFL glyphs within MusicXML
Identify and fix any remaining gaps or adoption barriers in SMuFL
Long Term:
Improve formatting support in MusicXML
Build a complete MusicXML specification document
Add Document Object Model (DOM) manipulation and interactivity to MusicXML.
Looking at the discussion, we saw a clear emphasis on the need for use cases, as well as the need to address foundational and structural issues in MusicXML. After reviewing all the responses, the co-chairs agree that these two areas deserve top priority, and that it makes sense to treat them sequentially. First we should focus on developing, refining and filtering a set of use cases for our notation format. After we have adopted a solid set of use cases, we can then turn to the foundational/structural issues in the standard with a much better shared understanding of our goals.
We believe document format discussions are best driven by use cases, expressed in terms of the needs and actions of different classes of users, as well as the nature and contents of the documents involved. Many of the discussions so far have been framed in terms of technology choices like MusicXML vs. MEI, XML vs. JSON, or IEEE 1599 vs. SMIL. We would like to begin re-framing these discussions to clearly identify user needs and document contents served by specific features in these technologies, rather than on whether we should pick technology A vs. technology B. Eventually we can shift to finding technical solutions that satisfy the use cases we deem worth addressing, in the context of this group’s charter.
Building an initial MusicXML specification met with some thoughtful push back. Peter Deutsch proposed that the specification effort should wait until the format is redesigned in some key areas to be more easily specifiable. Others mentioned that it may not be wise to do short-term work that would then need to be redone based on long-term goals.
People asked what adding support for use of SMuFL glyphs within MusicXML meant, and why a font standard influences a music representation standard. Our feeling is that there is an immediate practical need to add more musical symbols to the MusicXML format. A MusicXML update that includes greater support SMuFL’s expanded vocabulary of musical symbols will keep interoperability between applications high. We believe that this can be done with little risk of future rework based on long-term goals.
Identifying and fixing any remaining gaps or adoption barriers in SMuFL did not receive much feedback. There appears to be a feeling that the existing specification is in good shape, and mostly in need of incremental improvements in symbol coverage.
We therefore propose our short-term work cover three main areas:
Document the use cases for music notation formats in a way that can help drive decisions about the structural and conceptual changes needed in the standard.
Create a very focused, short-term MusicXML 3.1 update that addresses the need for broadening MusicXML’s symbol vocabulary and fixes some documentation bugs. This update will avoid any areas that are likely to be redone if structural changes are made in the future. We already have an initial take on what would be included in a MusicXML 3.1 update on Github at https://github.com/w3c/musicxml/labels/V3.1.
Produce incremental SMuFL updates as needed for enhanced symbol coverage.
We propose that these three items proceed in parallel. Joe will lead the use case documentation, Michael will lead the MusicXML 3.1 update, and Daniel will lead the SMuFL updates. We anticipate that the use case work will receive most of the group’s focus.
Our plan is for the co-chairs to put together an initial use case draft on the community group Wiki to illustrate what exactly we are thinking of when we talk about use cases. We plan to get that out within the next week or two.
Please let us know your thoughts on this proposed agenda update on the public-music-notation-contrib mailing list.
Thank you to everyone for your thoughtful discussion about the agenda for the Music Notation Community Group. Daniel, Joe, and I have consolidated the discussion on the CG Wiki at:
As a next step, the co-chairs will be working to adapt our initial agenda to reflect the ideas raised during this discussion. We hope to get that out to further discussion this week and see if we can start coming to a group consensus on how to proceed.
Thanks for your patience during the Northern-summer vacation season as things slowed down and many were out of town and offline. Even so, many new members and organizations continued to join the Music Notation CG, bringing the total count to an impressive 191.
Now, we’re finally at the point of getting started and actually doing something. With this post, the co-chairs hope to set a rough agenda for lots of good work to come. It’s also an opportunity to ask the membership to supply thoughts on a number of points where your input will be very helpful.
SO… NOW WHAT?
Let’s begin by reviewing some of the main areas in which we hope this CG can make progress. Of course we can’t do everything at once, although we can pursue some limited set of goals in parallel. We’ve broken these up into short-term projects that we think can be completed in the coming 6 to 12 months, and longer-term projects that can begin to be addressed in parallel with the short-term work, perhaps by separate subgroups within the CG.
SHORT TERM PROJECTS
Build an initial MusicXML specification. The aim of this initial document is tactical in nature: it needs to resolve the most significant ambiguities and gaps faced by developers working with the current version of MusicXML. It should also provide a framework for later, more complete specifications, and can serve as a version-controlled container for new MusicXML features going forward. This initial spec will be incomplete by design, though, and will still coexist/overlap with the current XSD documentation.
Add support for use of SMuFL glyphs within MusicXML. MusicXML needs to include some new constructs and documentation that allow SMuFL glyphs to be employed usefully. The symbolic vocabulary of MusicXML must grow to support some new SMuFL notations. MusicXML must also be able to specify the use of SMuFL glyphs in already-supported notations (e.g. “use this SMuFL notehead for this note”). More fundamentally, MusicXML must define the manner in which SMuFL glyphs are joined to each other and registered with respect to relative or default X/Y locations.
Identify and fix any remaining gaps or adoption barriers in SMuFL. We are at a point in this venture at which any serious problems or barriers to adoption need to be identified and fixed in SMuFL. It will be hard or impossible to fix such problems later.
Document music notation use cases. We need to begin to develop a separate document that covers and prioritizes the use cases that the CG’s work will support, to aid in evaluating the many alternative proposals and solutions that will come up.
LONGER TERM PROJECTS
Improving formatting support in MusicXML. MusicXML 3.0 formatting cannot easily be shared between documents. Nor can it distinguish formatting that clarifies semantics, such as for collision avoidance, from formatting that is more a matter of house style, such as font choices and spacing preferences. Could CSS stylesheets help solve these issues and provide more powerful formatting support for a wider variety of use cases?
Build a complete MusicXML specification document. A long-standing MusicXML community request has been to build a complete specification. This would replace the XML Schema as a specification and address holistic or cross-cutting matters that do not belong to any single schema component.
Adding Document Object Model (DOM) manipulation and interactivity to MusicXML. What would it take to be able to create interactive music applications on top of any standard MusicXML rendering engine? MusicXML was not designed with DOM interactivity in mind. Is the current document structure sufficient, perhaps with some minor adjustments? Or does the use of a time cursor that can move forward and backward, combined with the current structure, inhibit DOM interactivity? Would this require a more structural solution such as revisiting the MusicXML element hierarchy?
WHAT’S NEXT?
This is where the co-chairs can use your help. We’d like to ask you to answer the following questions:
Are these the right major goals? What’s missing? What should go?
Are we picking the correct short-term projects to start with?
Have we defined the short-term projects properly?
What would you most like to see done with MusicXML right away?
What would you most like to see done with SMuFL right away?
At this point we are looking for input from the membership. It’s tempting to indulge in a wide-ranging debate, but at this stage it’s going to be difficult to reach a conclusion through a large email discussion. So we want to begin by hearing people’s thoughts. Please send your thoughts to the contributor mailing list at public-music-notation-contrib@w3.org.
Thank you again for your interest in the Music Notation Community Group. We are looking forward to hearing your thoughts as to how you would like the group to proceed.
Welcome to the W3C Music Notation Community Group! 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. These users include, among others, software developers, music publishers, composers, performers, students, listeners, scholars and librarians. Some of the activities covered include composing, arranging, preparing, performing, teaching, learning, studying, and enjoying notated music.
Music notation formats have become much more interoperable over the past decade. There is still much room for improvement in making music notation work for the web and other digital applications. This includes improving music notation representation and music notation font formats for web and interactive use.
The initial task of the Community Group is to maintain and update the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle new use cases and technologies, including greater use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications.
Music Notation Community Group Co-Chairs Joe Berkovitz, Michael Good, and Daniel Spreadbury at MusicXML Community Meeting, Musikmesse 2015
Music notation has been on the web for most of its history, starting with proprietary applications like Sheet Music Direct and Sunhawk in the late 1990s. However, at that time there was no effective way to transfer music notation between applications. Desktop applications like Finale and Sibelius could not share music with each other, nor with the new generation of web applications.
Michael Good invented the MusicXML format in 2000 to create a standard interchange format for music notation applications. It has been adopted by well over 200 applications, including nearly all the major web, desktop, and mobile notation applications. Hundreds of musicians and developers have contributed to its development since MusicXML 0.1 was first announced to the public 15 years ago.
As people relied more on MusicXML for interchange, more focus emerged on the remaining problems in notation interchange. One major problem was the lack of standardization of music fonts. While there is a Western Musical Symbols range within the Unicode standard, it is too limited for most notation use and none of the major software applications use it. The lack of font standardization made it difficult to automate either document exchange or font substitution.
Daniel Spreadbury invented the Standard Music Font Layout (SMuFL) in 2013 to resolve these issues. SMuFL 1.0 was released last year and has received increasing adoption from font makers and software vendors. As with MusicXML, many software developers, font developers, and musicians have contributed to the SMuFL format since its public unveiling 2 years ago.
Both MusicXML and SMuFL have been managed as single company efforts with a single format editor making final decisions. Recordare developed MusicXML through version 3.0 before Recordare’s assets were sold to MakeMusic in 2011. Steinberg has developed SMuFL since its inception.
MakeMusic’s purchase of Recordare changed the dynamics of the MusicXML community. Recordare had been an independent vendor, generally not competing with other companies who implemented the MusicXML format in their products. MakeMusic’s Finale and SmartMusic products on the other hand compete with many products in the music engraving and music education markets. The past few years have also seen a lot of turbulence in the music notation market. MakeMusic and Noteflight have new owners; Daniel Spreadbury and many former Sibelius developers have moved from Avid to Steinberg.
All these changes have led to an increased desire to have music notation formats like MusicXML and SMuFL be developed by a standards organization independent of a single vendor. While some standards organizations have attempted to create new formats from scratch without leveraging the traction gained by existing formats, this group’s aim is to evolve standards that have actually taken root in the software community.
Joe Berkovitz from Noteflight/Hal Leonard has led the effort to move MusicXML and SMuFL development to a W3C Community Group. W3C Community Groups provide a way to combine the benefit of a standards organization while avoiding its drawbacks. First, W3C Community Groups have no membership fee, though companies can of course join the W3C if they wish full access to the W3C standards development process.
W3C Community Groups are also self-governing and can use a more rapid decision-making process than is usually required by standards organizations. MusicXML and SMuFL still need active development – for instance, to increase MusicXML’s support for the wider range of music symbols that SMuFL fonts offer.
The MusicXML and SMuFL communities need a home where updates to formats can still happen quickly without large additional costs. W3C Community Groups address this need, and pave the way for a potential later phase in which an open standard is approved as a full W3C Recommendation.
Another reason to move MusicXML and SMuFL development to the W3C is to support the growing use of music notation on the web, and the ever-increasing transition from paper to digital sheet music. W3C is the home to many web technologies that could benefit MusicXML and SMuFL, and MusicXML and SMuFL address difficult problems in the music notation domain that could help inform related web standards.
Michael and Daniel have discussed this potential change of governance with the MusicXML and SMuFL developer communities over the past few months, with Joe leading a discussion at this year’s MusicXML Community Meeting at Musikmesse. These communities are largely in favor of this change. The current host companies, MakeMusic and Steinberg, have also given their approval to transfer development of these formats to the W3C Music Notation Community Group.
The Music Notation Community Group’s initial tasks will be to maintain the MusicXML and SMuFL formats. There is an immediate need for a MusicXML update that has better SMuFL support and other smaller-scale fixes, clarifications, and updates. Over time, MusicXML has an opportunity to evolve to support more semantics behind notational appearance and better incorporate web technologies to support more use cases. The Community Group will determine which of these changes will happen in the next MusicXML update and which will occur in future releases.
Michael and Daniel are delighted that their companies have agreed to transfer development of MusicXML and SMuFL to the W3C Music Notation Community Group. Michael, Daniel, and Joe look forward to the community joining us in our new organizational home to continue moving music notation forward on the web, the printed page, and everywhere in between.
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 initial task of the Community Group is to maintain and update the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle new use cases and technologies, including greater use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications.
This is a community initiative. This group was originally proposed on 2015-07-27 by Michael Good. The following people supported its creation: Michael Good, Michael Cooper, Joe Berkovitz, Doug Schepers, Coralie Mercier. W3C’s hosting of this group does not imply endorsement of the activities.
w3c/smufl
Music Notation Community Group Co-Chairs Joe Berkovitz, Michael Good, and Daniel Spreadbury at MusicXML Community Meeting, Musikmesse 2015
