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.
Group'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.
The social media accounts for MusicXML on Twitter and Facebook that have been maintained by Michael on behalf of MakeMusic will be transferred into the stewardship of the W3C Music Notation Community Group, with Myke appointed as the new maintainer of these accounts. These accounts will be handed over to Myke around the time of Michael’s retirement in January.
As a reminder, the W3C Music Notation Community Group also has a YouTube channel where recordings of our in-person and online meetings can be found.
MNX
Issue #287 with the proposal for how transposing instruments and differences in part layouts should be handled is still awaiting community feedback, which would be most welcome!
In the meantime, Adrian has been working on trying out these proposals in the mnxconverter project, including some refactoring on the main branch to prepare for the proposed changes to how pitch is handled in MNX (using sounding pitch instead of written pitch). In conjunction with this, Adrian has also created a new branch (mnx-287) in which he has tried out the importing of MusicMXL files and transposing the pitches in there to sounding pitch using a simple algorithm.
We also discussed the accidental attribute of the note element (see examples here). At the moment, accidental redundantly specifies the type of accidental that is also expressed as part of the micro-syntax for the pitch attribute. After some discussion, we agreed that Adrian should write a proposal for changing the meaning of the accidental attribute to capture whether and how the accidental is shown using a simple enumeration. Adrian will write an issue outlining this proposal in the near future.
Next meeting
The next co-chairs’ meeting is scheduled for Tuesday 6 December 2022.
Michael Scott Cuthbert has agreed to take on the roles of MusicXML spec editor and co-chair of the W3C Music Notation Community Group to succeed Michael, who is retiring at the start of January 2023. Myke joined today’s meeting for the first time. We are delighted to welcome Myke as incoming co-chair and look forward to his contributions to the group’s efforts.
MusicXML
In a previous meeting, the idea was posited that the Dolet plug-in for Sibelius might be transferred into the guardianship of the W3C Music Notation Community Group, but the decision has been made that in due course MakeMusic will release the source code for the plug-in in a public GitHub repository licensed under the MIT License.
MNX
Adrian has created issue #287 to cover the proposal for how to encode instrument transposition. There’s a lot of detail contained in this proposal and we welcome feedback from the community. Adrian’s next step is to try these ideas out in the mnxconverter project with some real MusicXML data to see how it works in practice.
Next meeting
The next co-chairs’ meeting will be on Tuesday 22 November 2022.
MusicXML spec editor and co-chair selection process
The three co-chairs discussed at length the interviews that were held last week with the three excellent candidates to succeed Michael as MusicXML spec editor and Community Group co-chair. Daniel will be contacting the candidates soon to discuss the outcome of the selection process.
MNX
Adrian is still working on the proposal for how differences in enharmonic spelling between concert and transposed pitch scores and parts might be captured (issue #34), and expects to have a proposal ready for review soon.
SMuFL 1.5
Daniel has made some progress on some of the issues in the SMuFL 1.5 milestone (you can review the open pull requests here), and hopes to devote some more time to some of the remaining straightforward issues involving the encoding of new symbols in the coming week.
Next meeting
The next co-chairs’ meeting will be in four weeks, on Tuesday 8 November 2022.
Adrian brought an initial proposal for the encoding of pitches between transposed and concert pitch layout (issue #34) for discussion. The co-chairs have agreed on the basic details, and Adrian will present the proposal to the wider CG once some examples are a little more fleshed out.
MusicXML
As we prepare for Michael’s retirement, one of the issues he is looking to resolve is the future of the Dolet for Sibelius plug-in. MakeMusic has expressed the wish to convert the plug-in to use an open source license, and Michael asked his fellow co-chairs to consider whether the CG would be a suitable home for this plug-in. Another alternative would be for Michael to host the plug-in on a public respository himself, but he does not want to be responsible for the future maintenance of the plug-in. If any CG members have any thoughts or ideas about this plug-in, or would be interested in taking on the maintenance of the plug-in in future, they are welcome to the contact the co-chairs.
The three co-chairs are also in the process of scheduling meetings with the candidates who have expressed an interest in taking on the roles of spec editor for MusicXML and co-chair.
Next meeting
The next co-chairs’ meeting is scheduled for Tuesday 11 October 2022.
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 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.
Our community group meeting is scheduled to take place this Thursday, 15 September 2022, as part of W3C TPAC 2022. The meeting will be taking place via Zoom, and the Zoom link will be sent to you via email upon registration. If you do not register, either for TPAC or by completing our registration form, you will not be able to attend the meeting.
We look forward to seeing you there!
SMuFL 1.5
In advance of this week’s Community Group meeting, Daniel has been reviewing the issues in the SMuFL repository, and has now built up a set of 46 issues (and 2 pull requests) in the SMuFL 1.5 milestone. There are two issues in particular that we are interested in community feedback about at the moment:
After 44 years as a software engineer, I have decided to retire soon after my 65th birthday. My last day at MakeMusic will be Friday, January 6, 2023. At that time, I will step down from being co-chair of the W3C Music Notation Community Group, while remaining a group member.
The second half of my career has been spent in music notation software. I founded Recordare in 2000 to develop the MusicXML music notation standard, and MakeMusic acquired Recordare’s assets in 2011.
I envisioned Recordare as an Internet music publishing company. It didn’t get there on its own, but that is what we have today with the combination of MakeMusic and Alfred in Peaksware Music Brands. Meanwhile, the W3C Music Notation Community Group has provided an excellent organizational home for the MusicXML standard.
We will be discussing plans for future leadership of the W3C Music Notation Community Group at our annual meeting on September 15. I hope to see many of you there.
The pull request #285 for multi-measure rests (issue #284) has been merged and is complete. The remaining work to encode “old-style” multi-bar rests will be tackled later, and issue #286 has been raised to cover this.
Adrian is working on a proposal for the encoding of note spelling in different score/part contexts (issue #34) and hopes to have something ready to share ahead of the next co-chair meeting.
Community Group meeting, 15 September 2022
Our community group meeting is scheduled for Thursday, 15 September 2022 at 8:00am San Francisco, 11:00am New York, 4:00pm London, 5:00pm Frankfurt, 12:00am (Friday) Tokyo.
The agenda for the meeting is as follows:
Introduction to the Music Notation CG
Project updates
MNX
SMuFL
Instrument data
MusicXML
Organisational changes
Q&A
The co-chairs invite community group members to propose further agenda items that they would like to be added to the meeting by sending their suggestions via the public-music-notation CG mailing list.
As a reminder, the meeting is part of W3C TPAC 2022. As a reminder, if you are planning to attend any other sessions at the conference, you should register before 1 September. Please be aware that registration for this year’s TPAC attracts a fee, unlike last year’s conference. If you only plan to attend our Community Group meeting, then you do not need to register for TPAC, but you do need to register your intention to attend by completing this form. If you do not register, either for TPAC or by completing our registration form, you will not be able to attend the meeting.
Our community group meeting is scheduled to take place on 15 September 2022 as part of W3C TPAC 2022. If you are planning to attend any other sessions at the conference, you should register before 1 September. Please be aware that registration for this year’s TPAC attracts a fee, unlike last year’s conference. If you only plan to attend our Community Group meeting, then you do not need to register for TPAC, but you do need to register your intention to attend by completing this form. If you do not register, either for TPAC or by completing our registration form, you will not be able to attend the meeting.
As a reminder, the meeting is scheduled for Thursday, 15 September 2022 at 8:00am San Francisco, 11:00am New York, 4:00pm London, 5:00pm Frankfurt, 12:00am (Friday) Tokyo.
MNX
Adrian has created pull request #285 for issue #284 concerning the encoding of multi-measure rests. We plan to merge this pull request by the end of the week, so if you have any further feedback, please provide it as soon as possible. Use the links in the pull request to view the updated specification and the examples directly.
Next, Adrian will start working on the encoding of note spelling in different layouts (related to issue #34), following some earlier discussion between the co-chairs (May 24, 2022 meeting). Adrian will create a new issue with a proposal for this soon.
Next meeting
The next co-chairs’ meeting is scheduled for Tuesday 30 August 2022.
There has been some good discussion concerning the proposal for how to encode multimeasure rests (issue #284), and Adrian has charted a course through the feedback provided by the community to settle on a new proposal which can be found in this comment. Michael pointed out that we are using the term “measure” rather than “bar” in MNX so we will standardise on this term when encoding multimeasure rests as well.
We welcome any further feedback from the community, but absent any major objections we plan to move this to the pull request stage in the near future.
Next co-chairs’ meeting
Due to holidays, the next co-chairs’ meeting will be in four weeks on Tuesday 16 August.
w3c/musicxml
