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