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.
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.
Since our group’s priorities have become clearer over the past couple of months, the co-chairs have been working on revisions to the group’s charter in order to reflect the group’s current set of priorities.
The main proposed changes to the charter are as follows:
Update the timeline for the releases of MusicXML 3.1 and SMuFL 1.2
Explicitly identify the MNX container format, CWMNX and GMNX representation formats as the main deliverables of the group’s work
Propose that the initial versions of these three formats should be published by the end of 2018
Defines the development of test suites to support MNX, CWMNX and GMNX, and the development of software to aid in the conversion of MusicXML documents to CWMNX documents.
The procedure for changing a community group’s charter is that the revisions are proposed to the members of the group, who then have a period of 30 days to vote whether to accept or reject the revisions. Before we embark on the formal voting process, we would like to invite comments and feedback from members of the group.
The co-chairs propose that we have a period of two weeks for gathering feedback on the charter, and we ask that all feedback should be posted to the public-music-notation-contrib@w3.org mailing list before Monday 3 July. On or after Monday 3 July, the co-chairs will announce the formal start of the vote for the approval of the new charter.
Thank you in advance for taking the time to review the proposed changes to the charter. The co-chairs look forward to hearing your feedback.
We are happy to announce that beta versions of the Dolet 7 for Finale plug-in are now available from MakeMusic. You can download both the Mac installer and the Windows installer.
Dolet 7 for Finale adds support for reading and writing MusicXML 3.1 files. MusicXML 3.1 is the latest version of the MusicXML format and the first one to be developed within the W3C Music Notation Community Group.
By making Dolet 7 for Finale available for beta testing, we hope to assist other music software developers who want to add support for MusicXML 3.1 by being able to test exchanging MusicXML 3.1 files with Finale.
The MusicXML 3.1 features that Dolet 7 for Finale supports include:
Uncompressed MusicXML 3.1 files are now saved with a .musicxml file extension by default (issue 191).
Finale expressions with a mix of Maestro musical symbols and text are now exported and imported (issue 163).
Finale expressions with a mix of text and note symbols from other Finale built-in fonts are now exported (issue 163).
Unexpected symbols in Finale articulations can now be exported in a way that can be exchanged with other applications (issue 107).
Unexpected symbols in MusicXML files can now be imported into Finale articulations (issue 107).
Parenthesized accidental marks are now supported (issue 218).
Circled noteheads for percussion notation are now supported (issue 91).
The two styles of percussion clef are now distinguished during export and import (issue 64).
The n dynamic character is now supported (issue 52).
The sfzp and pf dynamics now use the corresponding new MusicXML elements (issue 52).
Highest / lowest notes without leger lines now use the standard MusicXML 3.1 feature for greater interoperability (issue 184).
Arrowhead characters in the Engraver Text fonts are now supported (issue 183)
Enclosures with 5 to 10 sides are now supported (issue 86).
The Dolet 7 for Finale plug-in is a 32-bit plug-in that works with Finale 2009 through Finale 2014.5 on Mac and Windows.
Please share your experiences with MusicXML 3.1 and the Dolet plug-in at the W3C Music Notation Community Group. If you find a problem with MusicXML 3.1 in your testing, please post an issue at the MusicXML GitHub repository.
Thank you for your help in making the MusicXML format an ever more powerful way to exchange scores between applications that use music notation.
The first beta version of the MusicXML 3.1 format is now available for developer testing. To get a copy, go the MusicXML GitHub repository at https://github.com/w3c/musicxml and click the “Clone or download” button. You can then either download a zip file or clone the Git repository on your local machine.
MusicXML 3.1’s main new feature is greatly enhanced SMuFL support. Many more SMuFL symbols are now represented directly by MusicXML elements, such as the <flip/> element for the brass techniques character located at U+E5E1. Other symbols can be specified by their SMuFL canonical glyph name in the MusicXML extension elements, using the “smufl” attribute. For example, there is no separate MusicXML 3.1 element for a brass valve trill, but it can be specified using the other-technical element:
<other-technical smufl=”brassValveTrill”/>
In addition to enhanced SMuFL support, MusicXML 3.1 has several other new features to improve interchange between music notation applications. These include:
A new “id” attribute is available on over 40 elements to allow specification of unique identifiers.
Musical symbols may be arbitrarily interspersed with text using the new <symbol> and <credit-symbol> elements.
Grace cue notes are now supported.
The measure element has a new “text” attribute to allow specification of non-unique measure numbers within a part. One case where this is helpful is when multiple movements are combined in a single MusicXML file, with each new movement starting at measure 1.
Ties are now allowed within metronome marks.
Images can now specify their height and width for scaling.
A new “time-only” attribute for the <lyric> element allows precise specification of which lyric is associated with which time through a repeated section of music.
A new “let-ring” type value for the <tied> element makes it easier to represent “let ring” or “laissez-vibrer” ties.
Additional polygonal enclosure shapes are allowed.
There is direct support for highest / lowest notes that are displayed without ledger lines.
MusicXML now has a recommended Uniform Type Identifier for macOS and iOS applications.
Compressed MusicXML files now have a recommended mimetype file to make it easier for applications to detect what type of zip file they are working with. This is similar to what is used in EPUB and other zip-based file formats.
The recommended file extension for uncompressed MusicXML 3.1 files is now “.musicxml” rather than “.xml”.
Many parts of the documentation have been clarified.
We look forward to hearing about your experience in implementing these new MusicXML 3.1 features. If you run into bugs or other issues with MusicXML 3.1, please create a new issue in the MusicXML GitHub repository.
The W3C Music Notation Community Group met in the Logos/Genius rooms (Hall 9.1) at Messe Frankfurt during the 2017 Musikmesse trade show, on Friday 7 April 2016 between 2.30pm and 4.30pm.
The meeting was chaired by CG co-chairs Joe Berkovitz, Michael Good, and Daniel Spreadbury, and was attended by about 40 members of the CG. A complete list of the attendees can be found at the end of this report, and the slides presented can be found here.
Peter Jonas from MuseScore recorded the meeting and has posted both video and audio recordings. Each recording is in two parts. The first part is for MusicXML and SMuFL, the second is for MNX. The videos are here:
Daniel Spreadbury (Steinberg, CG co-chair) presented a SMuFL 1.2 update. 33 of 42 issues are already fixed. The largest remaining issues implementation of Kahnotation and Spatialization Symbolic Music Notation (SSMN).
MusicXML 3.1
Michael Good (MakeMusic, CG co-chair) presented a MusicXML 3.1 update. 60 of 68 issues are already addressed. This is the last chance for a while to include anything not currently in scope, because after this most efforts will be focused on MNX. SMuFL 1.2 and MusicXML 3.1 should be released at the same time.
SMuFL coverage is one of the main goals in MusicXML 3.1. SMuFL glyphs can now be represented in MusicXML either using new elements, new entries in existing enumerations used by existing elements, or a means of specifying a glyph for an existing element using the new smufl attribute.
MusicXML 3.1 is adding a unique ID attribute to around 40 elements (e.g. measures, notes, directions, etc.) to allow unique identification of specific elements.
Musical symbols embedded in text can now be represented more cleanly using the new symbol and credit-symbol elements. These use SMuFL canonical glyph names as their values. You can’t use them by themselves: they must be used within a sequence of words or credit-words elements.
Grace cue notes can now be specified in MusicXML 3.1. This was a limitation of MuseData previously carried over to MusicXML.
You can now have ties in metronome marks. You can specify height and width values for embedded images. The new time-only attribute for lyrics allows you to specify which lyric is used on which pass through the music in repeats. The tied element can now have a let-ring type instead of requiring separate tied elements with start and stop types as used before. You can now use non-unique numbers for bar numbers to be displayed, which is helpful for scores that include multiple works.
Remaining work includes decisions on media types, UTIs for macOS and iOS, and media/MIME types. Michael asked if there were any objections to making this constellation of changes. Reinhold Hoffmann (Notation Software) asked if there were any real additional value in changing the recommended file extension for uncompressed MusicXML files, since it could cause some user confusion. Mogens Lundholm suggested that we should use .musicxml since there is no reason to stick to three character suffixes either. The meeting reached consensus that we should make these changes, and a preference for .musicxml as the recommended file extension. Michael will update the GitHub issues after the meeting.
A consideration of some things not currently in scope then followed. Is it OK to leave the remaining glyphs in the SMuFL ranges for plucked, string, and wind techniques as being only indirectly represented in MusicXML and instead leave them in the other-technical element using the smufl attribute? Some remaining documentation issues are due to lack of clarity in the MusicXML specification which have caused implementations to differ, and Michael doesn’t want to make changes to the documentation that will make existing applications wrong.
Michael is looking for implementations other than Finale and the Dolet for Finale/Sibelius plug-ins. James Sutton raised his hand as being likely to want to implement it soon. Gustaf, Soundslice, and Komp will all try to be among the initial implementations.
Reinhold asked whether it would make sense to participate only on the import side rather than also on the export side. Reinhold would want files from other applications to verify the import. He will discuss the schedule and see if this is possible.
MNX
Joe Berkovitz (Hal Leonard / Noteflight, CG co-chair) presented the current state of the MNX proposal. The current state of the proposal is a rough draft with a lot of gaps. It’s not a spec as it’s not rigorous enough, but the idea was to get something out to the community as quickly as possible.
Roadmap, Tradeoffs, and Rationales
There is a trade-off between three desirable qualities: semantics, interoperability, and generality. You can only have two of the three. A lot of the current discussion is around the ability to encode more music. Rich semantics and large vocabulary means an enormous spec and therefore a big implementation surface, which means a lot fewer implementations. A lot of generality and operability means worse semantics, instead using a general way of describing your subject matter, where you try not to model so much and let things speak for themselves. MusicXML occupies the middle ground between generality and interoperability, but MNX is going to allow a sense of compliance that can be clearly stated, which means a much tighter specification to prioritise interoperability.
The roadmap therefore looks like this: now, we’re looking at a way of encoding idiomatic Common Western Music Notation (CWMN), in the ballpark of what you see in works between 1600 and 1900. This does leave out many works, but it is intended to roughly as expressive but more interoperable than MusicXML.
As a corollary to this, we also need to take on the responsibility of developing a more general approach that would allow (more or less) any graphical approach to music that has time as an element of it. This will probably necessitate the graphics having to speak for themselves. We don’t yet have any recommendations on this: we should study some of the precedents (e.g. SMIL – Synchronized Multimedia Integration Language).
What about the middle ground? Scores that use many aspects of CWMN but which go outside of the conventions: we could call these “CWMN-inspired”. Ligeti is one example, but you could go a long way beyond Ligeti to include things that include invented notations alongside CWMN. Should we try and shoehorn this into the same structure we use for idiomatic CWMN, or should we instead move it towards the more general effort? The chairs think it has to go the second way, in order to protect interoperability and avoid having to build out the semantics further and further.
Dominik Hörnel asked about music that doesn’t fit cleanly into these two approaches, e.g. other music written before 1600 that isn’t specifically CWMN. Joe suggested that we might want to develop other profiles that draw upon some of the concepts we use in CWMN where appropriate. For dialects that have a shared understanding in the world, we can have idiomatic representations within the MNX family. Michael said that, when feasible, we could share the commonalities between different repertoires and allow the differences to be different.
Mogens Lundholm asked what are examples of things outside CWMN? Joe and Michael suggested Berio, Cage, aleatoric music where the performer has great freedom to play or not play various notes, etc.
Alexander Plötz asked whether we have a hard definition for idiomatic CWMN: can we describe what the boundaries are? We are going to have to decide what they are. We seek consensus but in the end we might not get there on everything.
Alexander also asked whether it would be appropriate to tackle the more general or more obscure notations, e.g. the Okinawan notation, now rather than later? Joe thinks that these might be good test cases for the MNX(graphics+time).
James Ingram said that it’s a mistake to think that CWMN has stopped developing: there are more general forms of CWMN that could be accommodated. James said that all symbols in music notation have “event symbols” which have meaning and a temporal element. CWMN has well-formed and efficient event symbols that we should build on rather than stating that evolution has come to an end.
Joe said that some time from now we will be able to identify the shared understandings that have emerged from the latter-day developments of western music, and address them with encodings that convey their spirit and meaning, but it’s the shared understanding that we don’t yet have in order to fulfil that goal. James responded that CWMN has been developed over hundreds of years to become very efficient and legible, and it would be a mistake to think that we need to forget this tradition and develop something else. As a composer it seems stupid that you can only put symbols in particular places: why not put them between them? James would prefer to generalise rather than to constrain.
Alexander asked whether MNX(graphics+time) should have a timeline with goals? Joe responded that we plan to include a rough timetable in the roadmap. Alexander said he would be more reassured if there were a timetable.
Alexander said that we are focused on interoperability: but who settled that? Michael replied that it’s in the charter of the W3C Music Notation Community Group. MEI is not as focused on interoperability, for example, as MNX is.
Hans Vereyken (neoScores) said that it’s very important to focus on as narrow a focus as possible. When you think about how it’s going to be adopted, narrowness is important in order to speed adoption. We won’t catch everything, but if the focus is there, we can develop more profiles. If we start too broad then we can’t get implementations.
Johannes Kepper (MEI) seconded this appeal to focus on a core subset, then only add things when there is a consensus from a larger group. Only when there is substantial need should you include it later. Johannes says that this is a learning from the development of MEI. Laurent Pugin (RISM) added that it would be a good idea to look at the other modules in MEI as a means of adding things to MNX: don’t make a new niche from an existing niche.
Christof Schardt (Columbus Soft) commented from the viewpoint of the implementer. Software exists because we accept limits. In order to make MNX a success, we have to agree on the constraints. Supporting idiomatic CWMN is enough. In the discussion group, some of our voices are slowing down the process. Expressed trust in the chairs and the ability to set the limits.
Alon Shacham (Compoze) said the group’s responsibility is to minimize the number of symbols, to make constraints.
Adrian Holovaty (Soundslice) suggested that since our focus is on interoperability, should we perhaps survey (say) the capabilities of the 30 top scoring programs to find the boundaries of what interoperability really means in a more scientific way?
Interoperability
Shifting to interoperability, why are we doing another format for CWMN? How do we achieve interoperability? Profiles and content types are mechanisms to prevent application developers from having to do everything: even within CWMN there will need to be a core profile that will exclude some more esoteric features.
We haven’t yet talked much about the MNX rendering model, but we need something that will help us to specify whether a rendering is conformant. L. Peter Deutsch and Christof Schardt have brought this up many times over the years. We need to allow enough wiggle room for applications to do what they think is right but hopefully we can arrive at something that allows us to specify what the baseline is.
CSS
Joe said that CSS is one of the hot button aspects of the spec. You could do MNX without CSS, but it’s the chairs’ view that it would be more painful without it. CSS is not there because CSS is a “webby” technology, though of course it is. It’s there because it’s a rule-based approach to styling in a way that is orthogonal to the structure of the mark-up language itself. Because it’s orthogonal it’s easy to ignore if need be. Also consider the use of CSS for the performance information: CSS can replace various sound-related elements in MusicXML. It could even inject specific MIDI-like interpretations that override the semantic representation.
The CSS selector/rule system may not capture the way that appearance of items are defined in scorewriter software. So maybe we should step away from it, at least from the point of view of exchange.
Matt Briggs (Semitone) said that as a C++ programmer, he is not very familiar with CSS. It could be written in XML elements rather than as a CSS string. Ad hoc styles look like “stringly-typed data”. If interoperability is a goal, then “easy to ignore” should not be a selling point. How do you constrain CSS content? It’s basically a list of properties that each element can have. Can we generate code from CSS like we can from XML schemas? Joe will follow up.
James Sutton asked about temperament. Michael replied that MusicXML does not support temperament directly: it does it by allowing you to specify precise MIDI pitches for each part. Could it be handled as part of the performance rules via CSS? James thinks it should be defined in an intrinsic manner for the pitch of each note.
James Ingram commented that the CSS could go into the SVG produced by the scoring application.
Christof expressed support for CSS because it can be applied to a standard set of data in lots of ways, e.g. to change the appearance of an existing score, in a powerful way. Producing variations of a single score is a key use case and using CSS makes that possible.
Cursors, Syntaxes, and System Notations
Joe realizes that the compact syntaxes in MNX could be controversial given that MusicXML has a very fine-grained element approach. For cursors and positioning, there are many possibilities for positioning directions in arbitrary places and we will need to decide.
Christof said we should avoid events having positions. He likes the fact that sequences don’t have positions, and thinks we should restrict positions to only non-event items. Offset vs. position: Christof thinks that offsets are semantically stronger than positions.
Michael agreed with Christof and mentioned that ticks can provide a high-resolution offset that is simpler than MusicXML’s divisions concepts. Daniel said he could not disagree more with what Christof and Michael have both said. Joe said that we will need to discuss this issue on the list; as you can see even the co-chairs disagree on this point.
Alexander proposed nesting sequences within an event to allow the positioning of non-note events within a longer note event.
Matt said that it could all be done without cursors. Events could be listed in sequential order, but with their position in time specified. Johannes says that this is how MEI also works, via “control events”.
Next Steps
Joe said our next steps are to apply course corrections based on this discussion, provide more MNX examples, and create and approve a roadmap document. After this we need to establish “beachhead” specifications for MNX(cwmn) elements and style properties, and begin reference implementation. We will continue open design discussion of MNX(graphics+time) in the background.
Generalized Notation
Joe said it should be possible to associate regions with arbitrary graphics with a progression of time, coupled with audio resources such as MP4 and MIDI data. In one set of applications, a semantic format could be converted into a graphics/audio format: compiling a score in a way that could be rendered by simple applications, with the graphics markup tracing back to the semantic data.
James Ingram discussed the Fauré “Après un reve” MNX example. The system element could represent tempo by specifying that the bar is 3000ms long, because 3/4 * 60 beats per minute, means that each bar is 3 seconds long. Instead of specifying durations in terms of length in quarter notes, instead specify duration in milliseconds so that it’s 1000ms. Could specify the duration as e.g. 980ms or add an additional event that is a grace note. The bar doesn’t have to add up in terms of CWMN, it just has to add up in time. Could have 5 quarter notes in there, even with different lengths, provided they add up to 3000ms. Tuplets are like beams: if a tuplet lasts for 2 eighths, it lasts for 1000ms, so you can add up the elements inside the tuplet with any values provided they add up to 1000ms. It’s useful to make them look like how they do in CWMN because they’re easier to read, but they could use any other symbols. So far this has been about metronomic time, but with recordings measures are at all different lengths, so this can be adjusted.
James Sutton commented that you’re basically throwing away all the higher order information in order to make something that looks like MIDI.
Additional Questions
Christof asked about the score container mechanism. We expect that applications will not accept every content type. MusicXML doesn’t provide a means of handling collections of music. The opus document type is not implemented by anybody. So multi-movement works of the same type, and different pieces of different types, can also be handled within the same container.
The meeting then moved on to a reception sponsored by Steinberg. Thanks to Daniel Spreadbury for arranging the sponsorship and taking the meeting minutes.
Attendees
Dominique Vandenneucker, Arpege / MakeMusic
Sam Butler, Avid
Amit Gur, BandPad
Antonio Quatraro, Biblioteca Italiana per i Ciechi
Carsten Bönsel, self
Dominik Hörnel, capella software
Bernd Jungmann, capella software
Christof Schardt, Columbus Soft
Alon Shacham, Compoze
James Sutton, Dolphin Computing
László Sigrai, Editio Musica Budapest
Sébastien Bourgeois, Gardant Studios
Joe Berkovitz, Hal Leonard / Noteflight
Edward Guo, IMSLP
James Ingram, self
Mogens Lundholm, self
Grégory Dell’Era, MakeMusic
Michael Good, MakeMusic
Heath Mathews, MakeMusic
Thomas Bonte, MuseScore
Peter Jonas, MuseScore
Johannes Kepper, The Music Encoding Initiative
Michael Avery, MusicFirst
Senne de Valck, neoScores
Hans Vereyken, neoScores
Reinhold Hoffmann, Notation Software
Chris Swaffer, PreSonus
Alexander Plötz, self
Laurent Pugin, RISM
Dietmar Schneider, self
Matt Briggs, Semitone
Martin Beinicke, Soundnotation
Adrian Holovaty, Soundslice
Daniel Spreadbury, Steinberg
Stijn Van Peborgh, Tritone
Mehdi Benallal, Tutteo
Cyril Coutelier, Tutteo
Mark Porter, Universität Erfurt
We look forward to seeing many of you at the W3C Music Notation Community Group meeting at the Musikmesse fair in Frankfurt. The meeting will be held on Friday, 7 April 2017 from 2:30 pm to 5:30 pm at the Logos/Genius conference room outside Hall 9.1. This is the same room where we held the meeting last year.
Here is our agenda for the meeting:
2:30 pm: Introduction, agenda, and sponsor message
For the MusicXML 3.1 discussion we have a few specific topics to cover:
Overview of what is new in version 3.1
Status of open issues
Does the list of issues in the 3.1 milestone on GitHub reflect what we want for MusicXML 3.1? Are there issues missing?
Timetable for release
We are still working on the organization of the MNX discussion. This will be based in large part on the lively discussion underway on the contributor mailing list.
Please sign up on our Google form at https://goo.gl/forms/MBBjVjnm3TzeZIz52 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 30 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
I am pleased to share with you an initial draft of a proposal for MNX. We hope this will be a useful starting point for the next revision of this group’s music notation standard. We look forward to fruitful discussions on this list, as well as in person in Frankfurt for those who are able to join us in April.
This has been a long time in preparation — far too long, I am sure — and I have little by way of excuse, even accounting for the unrelated work on my plate. However, this pause in output has at least given me the chance to think about the ideas presented here.
The phrase “starting point” is appropriate, as this document is still in a formative state. While some of the solutions may survive to a later stage of work, right now its purpose is to stimulate discussion by placing something concrete in front of us to examine and debate. Indeed, the co-chairs are not agreed on every element of the proposal, and much less would we expect agreement from the community group at large.
To that end, the document also seeks to capture conflicting points of view and alternate possibilities, which are noted as issues called out within the proposal. Rather than using specification language, the proposal relies on examples, to better allow experimentation with various answers to problems.
After an initial round of mailing list discussion, we will later move to using Github issues to track various points. The github repo is at https://github.com/w3c/mnx/ for version control details.
For now, the chairs look forward to some vigorous and positive exchanges of views on the public-music-notation-contrib@w3.org list! Please do use this contributor list for all discussion, in order to affirm that your contributions conform to the W3C IP policy.
This year’s face-to-face meeting for the W3C Music Notation Community Group will once again take place at the Musikmesse fair in Frankfurt. These meetings are always a highlight of our year as we usually have 40 to 50 music notation experts participating in the meeting and discussions.
This year’s meeting will be held on Friday, 7 April 2017 from 2:30 pm to 5:30 pm at the Logos/Genius conference room in Hall 9.1. This is the same location as last year’s meeting. As in our past meetings, we plan to have a 2-hour meeting followed by a 1-hour reception sponsored by Steinberg.
Our proposed agenda has two main topics: the status of MusicXML 3.1, and discussion of some possible next steps forward with MNX.
Originally we had hoped that MusicXML 3.1 would be shipping before Musikmesse. We have made good progress, but that goal was overly ambitious. We now hope to be feature-complete with MusicXML 3.1, or very nearly so, by the time of our meeting. We will provide an overview of MusicXML 3.1’s new features and discuss whether or not we are feature-complete and ready to proceed with testing and implementation.
MNX is our project for a next-generation music notation standard that does not need to be bound by 100% compatibility with the existing MusicXML format. Joe Berkovitz has been immersed in fleshing out some design ideas for an MNX Overview that we will discuss at the meeting. We will make a draft of this MNX Overview available for review ahead of time so we can have a more productive discussion of these design ideas.
SMuFL 1.2 is pretty much ready to go, awaiting the finalization of MusicXML 3.1 so we can be sure the two standards are in sync with each other. We will give a brief overview of SMuFL 1.2 status, but do not expect to be discussing it as much as the other two topics.
If you have additional ideas for agenda topics, please let us know either as a reply here or via the group mailing list.
Please sign up on our Google form at https://goo.gl/forms/MBBjVjnm3TzeZIz52 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 30 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
We hope that you have all had a happy holiday season and new year. Our progress at the W3C Music Notation Community Group was not quite as fast during the second half of 2016 as we had hoped, but we expect to pick up the pace in 2017.
Our first order of business is to finish the incremental releases of MusicXML 3.1 and SMuFL 1.2. Our new goal is to deliver these by the end of the first quarter of 2017.
We have made a lot of progress on MusicXML 3.1 in recent months. For the issues currently listed as in scope for version 3.1, 35 are closed and 21 are still open. With consistent focus on moving forward, it seems reasonable to be able to finish this within the next three months.
SMuFL 1.2 is largely complete. The main outstanding issue there would be the possibility of bringing the Kahnotation symbols for tap dance into SMuFL 1.2.
While Michael focuses on finishing MusicXML 3.1 and Daniel focuses on finishing SMuFL 1.2, Joe plans to focus on the MNX proposal for the next generation of music notation encoding. This work plans to start in February so that there are concrete proposals for the community to discuss at Musikmesse in April.
Several people have asked about a Community Group meeting at the NAMM show in Anaheim later this month. We have not scheduled a formal meeting for two main reasons: 1) we don’t have a lot of agenda items that seem to require a face-to-face meeting at this time, and 2) our Musikmesse meetings have been much better attended than our NAMM meetings.
However, it would be great to have an informal meet-up during the show. We have planned for dinner on Friday, January 20 at 7:30 pm. This will be at Thai Nakorn in Garden Grove. Michael and Daniel both plan to attend. Let us know if you plan to be there too.
We would plan our next formal meeting to be at Musikmesse in Frankfurt, where we could discuss some concrete proposals for MNX. We hope that we can have the same venue as in previous years, and similarly schedule it for Friday afternoon, April 7. If any company is interested in sponsoring the reception after the meeting, please let us know.
Thank you for your continued interest in the W3C Music Notation Community Group. We look forward to working together with you in the coming year.
Michael Good, Joe Berkovitz, and Daniel Spreadbury
W3C Music Notation Community Group Co-Chairs
In this post we’re taking the first of a series of steps that will establish a specification for the notation encoding standard that’s the subject of our work in this CG. The steps here are focused on a name, a mission and a high-level approach.
A Name, Of Sorts
We’re proposing the use of a code name for the next standard: something that we can use as a label, yet which is temporary in nature: it isn’t a committed naming decision. We feel that it’s not right to stick with MusicXML as the name for this project: it may suggest to some that it’s going to address the same use cases in the same ways as MusicXML, or that there may be some bias against evaluating ideas from other quarters.
For this code name, we’re proposing to call this project “MNX” for the time being. We don’t have to love this choice yet, because the name is replaceable. We just need something easy to say, easy to type and a bit open-ended. It stands for… “Music Notation X”, where X might mean the X in “extensibility”, or the X in “next”, or the call of the unknown, or the Roman numeral 10, or, perhaps, just a plain old letter of the alphabet.
What is MNX About?
Now that we have a name, however temporary, we’d like to make some statements about what MNX is intended to accomplish. These goals are only partly derived from the many use cases and scenarios discussed so far. They also represent the co-chairs’ ideas about how the CG should spend its time, and where the payoffs lie for stakeholders.
An Open Framework, But A Focused One
MNX provides an overall framework for encoding works of music of many different kinds. As such, it anticipates that more than one encoding system may be used, perhaps even within the same document.
The MNX schema will begin by describing a notation-neutral container that is concerned solely with a document’s metadata, attribution and organization. This part of this framework does not reference any notational system.
Inside the MNX container are one or more body elements of encoded music notation. These body elements can contain embedded documents of various types registered by some mechanism and policy to be determined. An MNX “body type” consists of an XML schema or sub-schema applying to some MNX body. An MNX body may also cite one or more document profiles that govern how its body is encoded, above and beyond the constraints of the XML schema itself.
There will be a way for those who wish to create their very own digital representation of notated music to do so, and plug that into an MNX document. However, only some set of recommended types are likely to be supported by other parties and their software projects. So there is an obvious incentive to use a recognized type to encode a work, rather than inventing one’s own. The work of the CG will focus on a small number of such recognized body type.
MNX comes bundled with a ready-made body type that supports Common Western Music Notation (CWMN), and which is biased towards a semantic representation of music. The encoded music is not required to reference any specific visual or aural rendering, although such information can be optionally included. This goal does not presume that there is a single unitary definition of CWMN, but the ways to tweak its boundaries must necessarily be limited in order to have a standard that solidly represents the vast majority of CWMN repertoire. Other body types will no doubt be invented to accommodate the gaps that result, and which make different design tradeoffs.
The CWMN body type and its associated document profiles are the heart of MNX: our primary intent is for MNX to support uses of CWMN across the various user communities described in our use cases document, serving creative, academic and commercial interests alike. The hope is that MNX will at least inherit the degree of support found for MusicXML today, and will hopefully address many unmet needs of other musical constituencies.
The initial work of the CG, therefore, will lie in elaborating the CWMN body type for MNX. Other body types will fall inside the circle of recommended types, of course, while yet others will be works-in-progress or experimental prototypes. These other body types will, at first, be the work of voluntary subgroups.
Something Borrowed, Something New
MNX is not starting from scratch: there’s a lot of useful work to draw on. We should strive to avoid reinventing the wheel. Rather than repeat some of the areas where MNX intends to innovate (e.g. styling, profiles), this section looks at some of the key existing work that we can make use of today.
MEI does a great job of organizing musical texts with their attached metadata in an arbitrary structure (the “container” spoken of above). MEI’s approach to metadata overall is very thoughtful and more comprehensive than what is available in MusicXML.
MusicXML has a rich semantic vocabulary for CWMN proven by time and adoption.
MusicXML can cope with a wide range of conflicts between visual notation and the intended aural rendering
The MEI CWMN schema has a simpler approach to organizing elements that is more friendly to a DOM-based approach.
Other projects including CMME and NeumesXML have looked at encoding neumes and mensural notation, and these should be examined for potential adoption or adaptation.
Next Steps
The best next step would be to create a family of spec documents that begin to capture the most significant ideas that we want to employ. These initial drafts will document concrete directions that can be discussed. They will follow the overall structure and formatting of other W3C specs in HTML, and will draw on W3C’s internal specification toolset ReSpec.
We propose that the initial emphasis be placed on two specifications:
The MNX container. MEI has already done a great job developing the concepts needed for a good approach to a container, and it’s possible that not much new ground may need to be broken here. Perhaps the key challenge here is that the notion of body type will need to be worked out and elaborated.
MNX support for CWMN encoding. We expect the CWMN encoding piece to draw on the terms, concepts and vocabulary of MusicXML, but reworked to better support current encoding and programming best practices. A key part of this work will be the development of a family of CWMN document profiles that can significantly lighten the development burden. To leverage MusicXML adoption, the specification will be developed together with automated software to convert existing MusicXML files into MNX CWMN files.
We expect another round of discussion on the CG list, naturally, but we wanted to take this opportunity to share our thoughts so that we can begin together on the next — and very exciting — bunch of work.
Joe Berkovitz, Michael Good and Daniel Spreadbury
W3C Music Notation Community Group Co-Chairs
The W3C Music Notation CG met in Genius/Logos (Hall 9.1) at Messe Frankfurt during the 2016 Musikmesse trade show, on Friday 8 April 2016 between 2.30pm and 4.30pm.
The meeting was chaired by CG co-chairs Joe Berkovitz, Michael Good, and Daniel Spreadbury, and was attended by about 40 members of the CG. A complete list of the attendees can be found at the end of this report, and the slides presented can be found here.
SMuFL 1.2 update
Daniel Spreadbury (Steinberg, CG co-chair) presented a brief summary of the state of the SMuFL 1.2 development effort, with 30 issues currently open and an expected delivery date of no later than the end of Q3 2016.
There were no substantive questions or discussion raised by this update.
MusicXML 3.1 update
Michael Good (MakeMusic, CG co-chair) presented a brief summary of the state of the MusicXML 3.1 development effort, with 37 issues currently open and an expected delivery date of no later than the end of Q3 2016. Michael also explained the basic procedure of how issues will be resolved using the GitHub issue/discussion/pull request workflow, and offered help on behalf of the co-chairs to any member of the CG who is daunted by or has questions about this workflow.
James Sutton (Dolphin Software) expressed concern about the noisiness of the emails generated by the GitHub issue/pull request workflow. He suggested that the ideal solution would be to provide a series of opt-ins/opt-outs for different kinds of automatic emails, if possible.
ACTION: The co-chairs agreed to investigate what possibilities might exist with their contacts at the W3C.
User stories
Werner Wolff (Notengrafik Berlin) prefaced Joe’s presentation on how user stories should inform the capabilities of the new notation representation by asking how we as a CG should engage the wider music writing community, and to get to the core of what music notation really means?
James Ingram suggested that the requirements identified by the MPEG-sponsored effort to define a new representation for music notation should be included in our user stories.
ACTION: James Ingram to produce a link to the MPEG user stories.
What should the scope of the effort be?
Following discussion of what kinds of musical works should be considered to be in scope for the capabilities of a new representation format, with a couple of examples cited by Joe including George Crumb’s Makrokosmos (with its circular staves) and Frédéric Chopin’s Prelude no. 15, or Raindrop Prelude (with note values that appear to exceed the time signature) posited as those that might be sufficiently complex that some aspects might be considered out of scope.
James Ingram and Werner Wolff were both of the opinion that all scores of all kinds should be representable in the standard. Zoltan Komives (Tido) argued that certainly if Chopin is considered out of scope, the scope is too narrow. Christof Schardt (PriMus Software) argued that the current version of MusicXML can represent the visual appearance of Chopin’s Raindrop Prelude quite adequately by reproducing the techniques used in engraving programs like Sibelius and Finale required to produce the desired appearance.
Werner Wolff raised the question of where graphical notation, as distinct from CWMN, can be considered to start? Does, say, a heart-shaped notehead constitute a graphical notation?
James Ingram suggested that it would be possible to use a combination of a purely visual representation (e.g. SVG) and a purely aural/temporal one (e.g. MIDI) to make it possible to capture these different semantic dimensions.
Ron Regev (Tonara) expressed that there is a conflict between making the standard all-encompassing on the one hand and easy to work with on the other, mirroring a point made in Joe’s slide that the tighter the semantic restrictions, in general the easier the format is to work with.
Encoding profiles
Joe presented the idea of encoding profiles for documents in the new notation representation, as a means of expressing the intent behind the encoding and informing a consuming application (and end user) what capabilities an application must have to be able to work with that particular document.
Thomas Weber suggested that the “menu” approach taken by the various kinds of Creative Commons license, presenting content creators with a set of checkbox options for what kinds of uses are permitted and prohibited, might be an approach to how an encoding profile could be made. Joe suggested that in fact each individual profile might be more like one of the checkboxes in the CC licensing set-up process.
Jan Rosseel (Scora) pointed out that if these profiles are going to work, they will need to be enforced in the editing applications used to author the content as well as in the documents themselves.
Zoltan Komives explained that profiles are a core part of the MEI framework, where they are known as customisations, and summarised their role as a contract between the producer of the data and the consumer of that data.
Architectural suggestions
Joe went on to present some suggestions about how the new notation representation could be architected, including the idea of cleanly separating semantic, visual styling, and performance (or playback) data in a manner similar to how the semantics and visual dimensions of web pages are separated into HTML (semantic) and CSS (visual). He also proposed that following the DOM approach makes creating interactive experiences driven from symbolic music representations easy. Joe demonstrated this with a toy application that uses a combination of MusicXML data, JQuery, HTML, CSS, and Noteflight’s embeddable MusicXML renderer, to produce a simple music theory quiz in a few dozen lines of code.
Note that there is not yet any public, online version of the software shown here.
Adrian Holovaty (Soundslice) asked whether the proposal for CSS-like description of visual aspects of notation would actually use CSS, or a new language? Joe responded that it would make sense to borrow some of the CSS entities directly (e.g. color) but that there would be a lot of work to do in defining entities that make sense for music notation (e.g. dimensions might want to be expressed in stave units rather than in, say, pixels or points).
Zoltan Komives commented that music notation is a means of describing art with art, adding that Tido has found CSS to be insufficient to describe the visual aspects of music notation, and has already made some progress in defining a new language that attempts to do this. Joe asked Zoltan if he could share any observations about the unsuitability of CSS.
Action: Zoltan to prepare some comments for the CG about Tido’s experiences with using CSS to style music visually.
James Ingram presented the idea that the visual dimension can be thought of purely in terms of space, and the performance or aural dimension can be thought of purely in terms of time: in his view, everything is either time or space. This seemed to be a controversial view among the attendees of the meeting, with Alexander Plötz asking whether information about the forces required to perform a work (e.g. labeling one of the staves as being played by a flute) would be considered “space” or “time” in James’s division of responsibilities, to which James replied that it would be “space.”
Thomas Weber commented that he felt it would be necessary to extend the DOM in the same way that SVG has done in order to make the kinds of high-level interactive experiences outlined by our user stories possible; in particular, Thomas expressed concern about how to handle the complex relationships between different entities, e.g. to ensure that if you edit the duration of one note in a bar, this may well have consequences for other notes in the same and indeed other bars. Music is not as cleanly hierarchical as other standards or types of content. Michael suggested that XPath or other similar technologies might be useful to help link separate entities together and move towards solving this problem.
Adrian Holovaty expressed concern about using DOM programming to achieve these interactive user stories because this approach implies that the music notation representation is transmitted in full to the client’s computer, which may have implications both for performance and security (e.g. rights management). Adrian explained that although Soundslice uses MusicXML for the representation of the music, it is transmitted to the end user’s browser by way of an intermediate format. He expressed concern that developers and rights holders alike might find obstacles and objections to this approach.
Thoughts on scope and feasibility
As the meeting drew towards its close, the attendees returned to the discussion of what the scope of what the CG can hope to achieve might be.
Werner Wolff appealed for keeping the scope as broad as possible, while recognising that the music industry is small in comparison with other industries, and resources (time and money) are comparatively scarce. However, he did not want the CG’s work to immediately head to the lowest common denominator and leave many niches of musical expression on the outside.
Reinhold Hoffmann (Notation Software) made the counterpoint that the CG’s work must be market-driven, based on what is feasible from a time and effort perspective, and geared towards the needs of consumers; in other words, a pragmatic approach.
Christof Schardt expressed support for the need that the new representation format must break compatibility with MusicXML in order to be able to solve the big problems. Michael responded that he agreed that breaking changes would be necessary, but cautioned against making breaking changes only on the grounds of preferring the elegance of a new solution. To minimise the effort required by those applications and technologies that already support MusicXML, if a use case is already adequately met by an existing capability of MusicXML, the CG should not be in a hurry to throw it away purely because we have come up with a more elegant solution.
The co-chairs thanked the attendees for their attendance and participation in the meeting, which closed with a drinks reception generously sponsored by Newzik.
Attendee list
Manfred Knauff, Apple
Dominique Vandenneucker, Arpege / MakeMusic
Jan Angermüller, self
Ainhoa Esténoz, Blackbinder
Sergio Peñalver, Blackbinder
Gorka Urzaiz, Blackbinder
Brenda Cameron, Cambrian Software
Dominik Hörnel, capella software
Bernd Jungmann, capella software
Wincent Balin, Columbus Soft
Christof Schardt, Columbus Soft
James Sutton, Dolphin Computing
Hans Jakobsen, Earmaster
James Ingram, self
Michael Good, MakeMusic
Thomas Bonte, Musescore
Mogens Lundholm, MusicXML-Player
Bob Hamblok, neoScores
Aurélia Azoulay, Newzik
Pierre Madron, Newzik
Raphaël Schumann, Newzik
Reinhold Hoffmann, Notation Software
Martin Marris, Notecraft Services
Joe Berkovitz, Noteflight
Werner J Wolff, Notengrafik Berlin
Thomas Weber, Notengrafik Berlin
Werner Eickhoff-Maschitzki, Notengrafik Eickhoff, Freiburg
