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.
A week ago, on 5 March, the W3C Music Notation Community Group reached another significant milestone, with the publication of the Standard Music Font Layout (SMuFL) specification, version 1.3.
We addressed some 49 issues in SMuFL 1.3, expanding the repertoire of characters in the standard (including significant new ranges for German organ tablature and Kahnotation), and clarifying aspects of the specification.
Attention now turns to a potential SMuFL 1.4 release, for which we have created a milestone in GitHub and to which we have assigned the majority of the outstanding issues. If you have any ideas or proposals that could form part of the next SMuFL release, please create an issue so that we can begin discussion.
We will provide a short wrap-up on SMuFL 1.3 and a quick look ahead to SMuFL 1.4 at the forthcoming meeting at Musikmesse. If you are planning to attend, but haven’t yet let us know that you’re coming, please do so now. We look forward to seeing you there!
Michael and Adrian congratulated Daniel on the publication of the spec, and the co-chairs ceremonially made their licensing commitments. Daniel agreed to write a blog post announcing the release of the report and requesting that others make their own licensing commitments.
Introduction to MNX
Michael and Daniel have provided feedback to Adrian on the draft of the introduction to MNX that he has written.
Adrian was struggling to fit MNX-Generic into the narrative of the post and wonders whether now MNX-Generic is sufficiently different from MNX-Common that it should perhaps be a completely separate format. He has three reasons:
It’s confusing for users to have two kinds of MNX. Which one should users choose? How would the user understand the differences in the level of semantics between the two formats?
It’s confusing for developers, too. The type of development work required to parse something that is essentially an SVG wrapper versus a semantic tree-based document model is almost completely different. Adrian’s guess is that the majority of developers would only want to do one of them.
There’s no obvious benefit in having them wrapped together in the same format apart from some negligible stuff like sharing the metadata format.
Michael expressed agreement with all of these points. Part of Joe’s motivation for the decision to bring MNX-Generic into the standard was to attract people from other communities, e.g. from the MEI community. But having a family of specifications maintained by the same organization may be sufficient to address that goal.
This is already captured as issue #98, which the co-chairs agreed to place under active review.
Michael also pointed out that the MNX names are still considered code names, so we could even decide to call them different things at the end. Daniel expressed agreement with Adrian’s points.
Michael said that rather than the naming issue, the more critical issue is the notion of whether MNX is a generic container format. In many ways an MNX container would be no more useful to a software application than e.g. a zip file. It would not be obvious without looking inside it what it contains and what to do with its contents. The co-chairs agreed to defer further discussion on the container format until the wider issue is settled.
Adrian clarified that he thinks it’s crucial to do the job of MNX-Generic but the issue is how the two formats are positioned.
The co-chairs are in broad agreement that we should focus MNX on the semantic format currently known as MNX-Common and move the MNX-Generic format to a separate specification. We will invite feedback from the user community about whether we are overlooking any advantages to the current approach, for feedback about the idea of separating them, and to solicit ideas for names for a newly-separated format.
Michael will slightly reorganise the order of the pages on the Wiki to make sure the spec is prominently displayed there.
Adrian’s introduction will be published as the README.md in the MNX repository, so it will eventually appear as the root of https://w3c.github.io/mnx.
CSS in MNX
Adriam raised the issue of using CSS-like styling in MNX, which is currently part of the draft specification. Although he thinks it’s conceptually a beautiful idea, it will probably be impractical to embed CSS syntax directly in the format because it will require the building of a whole parallel parser. Michael agreed, and there was brief discussion about how we should take the aspects of CSS that work for us and build an XML-friendly approach that fits into the existing XML parser. We know that this was something of a controversial approach among the community for this reason anyway.
The co-chairs reflected that all of the decisions that have been taken to date on MNX are still fungible, provided we have consensus from the community.
Sounding vs. written pitch
Adrian will review the recent discussion on issue #138 concerning sounding vs. written pitch and bring it together into a set of pros and cons. The aim is still for the co-chairs to have sufficient time to come up with a concrete proposal that takes the discussion into account ahead of the Musikmesse meeting. We aim to formalise this proposal in our next meeting in two weeks.
DAISY Music Braille
We haven’t yet received the promised documents from the DAISY Music Braille group, which were expected on 1 March. Daniel reported that Matthias Leopold from DZB in Germany plans to attend the Musikmesse meeting.
Preliminary Musikmesse meeting agenda
Michael will send an email reminding people to sign up to let us know they’re coming and to solicit agenda items. The current preliminary agenda looks like this:
SMuFL 1.4 plans (Daniel will assemble an issue list etc.)
MusicXML 3.2 plans (Michael will assemble an issue list etc.)
DAISY Braille Music group and its requirements (Daniel will ask Matthias if he wants to speak)
MNX topics (probably MNX-Generic vs. MNX-Common, CSS in MNX, sounding/written pitch)
Michael will contact Peter Jonas at MuseScore to see if they will be able to provide an audio and/or video recording of the meeting.
CLA enforcers for GitHub
Adrian has done some research into CLA enforcers, and identified a number of possibilities to ensure that community members sign up to the CLA before they make contributions (definitely for pull requests, and possibly for raising issues) so we can be sure of compliance. Adrian will send the candidates to the other co-chairs for discussion, and then we’ll run our proposal past our contacts at the W3C.
Next meeting
Our next meeting is scheduled for Tuesday 19 March.
Our Community Group’s in-person meeting at the Musikmesse in Frankfurt is set for Thursday, April 4. We discussed travel logistics. All three co-chairs will be in attendance.
The SMuFL 1.3 Community Group Final Report is essentially done. Several community members have reviewed it, and we’re not planning any more changes. The remaining step is coordinating the publication with the W3C, to make it official.
Moving forward with SMuFL, Daniel has reviewed all the open issues in the GitHub issue tracker and moved outstanding ones to a new milestone for Version 1.4. He also closed a few others that he determined were out of scope.
In MusicXML news, Michael plans to create a Version 3.2 milestone in the GitHub issue tracker and do similar issue gardening. Michael also plans to make a proof of concept for a new idea regarding richer support for parts within a score; when he has it, he’ll create a proposal on GitHub.
The DAISY Music Braille Project has recently been in touch with us and wants to engage more deeply with our community. At the basic level, they’d simply like our community to be aware of them as a resource; on a deeper level, they have specific requests for new MusicXML/MNX features. Daniel has an upcoming meeting with a representative, and they’ll discuss the best way to triage these features. We’d also like to see whether any DAISY folks can attend our Musikmesse meeting.
We’ve recently received several ideas and bug reports in our GitHub issue tracker from folks who haven’t yet formally joined the community group — and, hence, haven’t transferred their IP rights to the group (i.e., signing the CLA). As such, to be safe, we can’t respond to these issues until they take that step. Aside from continuing to contact these people one-by-one, there might be a technical solution: requiring GitHub contributors to sign a CLA in order to post issues or pull requests. Adrian is going to investigate this.
In MNX news, there’s been some activity recently in the GitHub thread regarding pitch representation (MNX issue 138). Adrian is continuing to work on an MNX “overview for laypersons” document and plans to have a draft this week.
Adrian brought up a few MusicXML oddities he’s seen in the wild recently, and Michael gave historical context and thoughts on the best way to handle them. One of the out-of-the-ordinary notations Adrian came across — a C clef centered on the C staff line — got the co-chairs talking about MNX’s definition of clefs (which is yet undesigned) and how it should perhaps let people specify a staff position (i.e., including staff spaces) instead of only staff lines. Adrian will file this in the MNX issue tracker.
Our next meeting is scheduled for Tuesday, March 5.
We are pleased to announce that we will have a face-to-face meeting of the W3C Music Notation Community Group at the Musikmesse in Frankfurt. We look forward to this event each year as we usually have 40 music notation experts participating in the discussions.
This year’s meeting will be Thursday, 4 April 2019 from 2:30 pm to 5:30 pm in the Apropos meeting room in Hall 3, Level C. This is the date that worked best from our Community Group poll, and fits in with the new Musikmesse schedule that runs Tuesday through Friday.
As in past years, we will have a 2-hour meeting followed by a 1-hour reception. This year’s reception will be sponsored by capella-software.
The meeting agenda will include updates on the current status and future plans for SMuFL, MusicXML, and MNX. We plan to discuss some of the most important outstanding MNX issues, including pitch representation and the connections between scores and parts.
You will need a Musikmesse trade visitor ticket to attend the meeting. These cost 30 euros and are available online at www.musikmesse.com.
Please sign up on our Google form at https://goo.gl/forms/mIz5rFqyguRX43ku2 if you plan to attend the meeting. This will help ensure that we have enough room and refreshments for everyone.
We look forward to seeing you in Frankfurt!
Best regards,
Michael Good, Adrian Holovaty, and Daniel Spreadbury W3C Music Notation Community Group co-chairs
One of the suggestions made at the Music Notation Community Group NAMM meeting was to publish the minutes of the co-chair meetings, which generally happen every 2 weeks. Here is the first of these minutes.
We discussed the status of the SMuFL 1.3 Community Group Final Report. Two small edits have been made to fix typos in the published draft. A few other people have reviewed this draft without requesting changes. We plan to send out a reminder next week about reviewing the report.
If all looks good, we plan to publish the Final Report the week of February 18, 2019. Daniel will contact W3C staff to see if there are steps we need to take on GitHub before publishing the final report. We need to better understand exactly what gets copied to the W3C site when the report is published. The SMuFL report is more complex in this respect than the MusicXML report we published earlier.
We discussed the document that Adrian is writing about positioning of MNX and MusicXML. This will likely be initially published on the group Wiki, with a goal of evolving it into a preamble for the MNX specification. The MNX preamble could work like the SMuFL report preamble, detailing the motivation for the specification before diving into the details. This document will then be followed by Adrian’s blog post asking for guidance on pitch representation issues from a larger developer community beyond the Community Group.
Michael has not yet heard back from Musikmesse about a room for a Community Group meeting. He plans to follow up with Musikmesse later this week.
The next co-chair meeting is scheduled for Tuesday, February 19.
The W3C Music Notation Community Group met at Room 201C in the Anaheim Convention Center during the 2019 NAMM trade show, on Friday, January 25, 2019 between 3:00 pm and 4:00 pm.
The meeting was chaired by CG co-chairs Daniel Spreadbury and Michael Good, and was attended by 25 members of the CG and interested guests. The slides from the meeting can be found at
Philip Rothman from the Scoring Notes blog video recorded the meeting and has posted it on YouTube. Dominik Svoboda audio recorded the meeting and his audio is included in the video. The video starting times for each part of the meeting are included in the headings below.
Introduction to the W3C MNCG (Starts at 0:02)
Daniel Spreadbury introduced the W3C and the Music Notation Community Group. Daniel reiterated the importance of joining the group in order to make any contributions to the work of the group on SMuFL, MusicXML, and MNX. The web user interface for joining the group is not very easy, so please reach out to one of the co-chairs if you have difficulties.
Daniel discussed the changes in the group over the past year, in particular the change of co-chair from Joe Berkovitz to Adrian Holovaty. Given Joe’s absence, MNX was largely static over the last 6 months of 2018, but we look forward to resuming progress with Adrian’s leadership on MNX. Daniel will continue to lead work on SMuFL and Michael will continue to lead work on MusicXML. Adrian was not able to attend this year’s NAMM but does plan to attend our Musikmesse meeting.
SMuFL (Starts at 7:39)
Daniel Spreadbury led a discussion of the current status and future plans for SMuFL. Our immediate goal is to release a W3C Community Group Final Report for SMuFL 1.3. There was a previous draft 1.2 version of SMuFL, but this did not make it to an official Community Report.
At the time of the meeting the draft of the final report was close to publication but not yet released. (It was published at https://w3c.github.io/smufl/gitbook/ a few days after the meeting.) The main changes include new ranges for Kahnotation and German organ tablature, along with extensions to a few existing ranges and more stylistic alternates.
Currently there are 7 fonts available that support SMuFL: Bravura, Petaluma, Gootville, Leipzig, November 2, and MTF-Cadence. Bravura is intended as the reference font for SMuFL and contains all the glyphs that are part of the SMuFL 1.3 report. The other fonts cover the common music notation ranges but not the complete list of SMuFL ranges.
After the final Community Group Report is released for SMuFL 1.3, SMuFL will continue to evolve. There are around 30 issues currently outstanding that were not addressed in 1.3, and a 1.4 release is possible later in 2019.
We look forward to reviews of the draft report. The SMuFL GitHub repository is the preferred location for reporting issues. We expect to have at least 2 weeks for review after the draft report is published.
Hans Landval Jakobsen asked if there are any font technology requirements such as TrueType for SMuFL fonts. Daniel replied that there are no font technology requirements aside from being able to support code points in the Private Use Area of the Unicode Basic Multilingual Plane. All SMuFL fonts released so far have been OpenType fonts, including OpenType fonts with PostScript outlines.
MusicXML (Starts at 22:06)
MusicXML 3.1 was released in December 2017 so no changes have been made in MusicXML since then. Companies have been busy implementing MusicXML 3.1 features over the past year.
Michael proposed starting work on a new version of MusicXML in parallel with ongoing MNX development work. This is a change from the previous plan where we wanted to wrap up MusicXML 3.1 development to focus on MNX. However, with the changes in the working group co-chairs and evolving needs for MusicXML exchange, it seems to make sense now to work on both in parallel.
Michael discussed potential issues that could drive a MusicXML 3.2 release. The exchange of information about the differences between score and parts has become a key pain point for MakeMusic’s work in exchanging between its Finale and SmartMusic products. This is something MakeMusic would like to see resolved in a standard fashion, rather than a MakeMusic-specific workaround. A related issue is MusicXML 3.1’s incomplete support for concert scores that are associated with transposed parts. Currently there are 92 open MusicXML issues at Github, so there is plenty of scope for choosing what to work on for a 3.2 release.
Doug LeBow asked if any of the major music preparation houses has seen the list of potential MusicXML issues. Michael expects that nobody has looked at this list in a long time, but now would be a good time for people to join the Community Group to help drive the selection of MusicXML 3.2 issues. The list of issues could also be cleaned up and tentatively organized into a MusicXML 3.2 milestone.
Jason Freeman asked if there was a reference implementation for MusicXML, or could there be? The Community Group had earlier decided to postpone the issue of a reference implementation to work on MNX. For MusicXML, Finale is probably the most complete implementation, but it is not a reference implementation – it is neither complete nor open source.
Jeff Kellem suggested that building up a standard test suite over time could be an important contribution for developers. Michael agreed and thought this was more feasible than a reference implementation – we could start small and iterate over time, independent of MusicXML releases.
MNX (Starts at 39:35)
We have an initial draft MNX specification available at GitHub. The co-chairs believe it provides a solid technical foundation, but there is still a lot of work ahead to get to a complete draft.
Our plans for 2019 are to ramp back up on MNX development. We plan to start by finalizing a set of interrelated issues regarding pitch representation, including using written pitch vs sounding pitch and encoding the relationship between score and parts. We would like to have a discussion of this at our Musikmesse meeting and get these issues resolved shortly afterwards.
Doug said that MusicXML and MNX each have their own strengths, so developing them in parallel seems like a good idea. But he is unclear on what exactly MNX can add to what MusicXML already does. Michael responded that this is a common source of confusion, and Adrian is planning to write a document to help address what we are trying to accomplish with MNX.
Jeremey Sawruk suggested that if we are going to do MusicXML and MNX development in parallel, perhaps we could develop the test suites in parallel as well. That might clarify some of the differences between the two formats.
In general, the attendees at this meeting appeared to agree that doing MNX and MusicXML development in parallel was a good idea.
Next Steps (Starts at 48:15)
We discussed next steps for the Community Group, including our plans for meeting at Musikmesse, which will be held in Frankfurt between April 2 – 5.
Fabrizio Ferrari asked about ways to communicate more often aside from the two face-to-face meetings and the nitty-gritty of the individual GitHub issues. Perhaps the co-chairs could send out a periodic digest of the issues we are discussing? Chris Koszuta suggested sending this digest out on a weekend to avoid conflicts with an overload of other business emails. Jason suggested sending out summaries of the co-chair meetings.
Chris also suggested simulcasting the face-to-face meetings for people who could not travel to the USA or Europe, as the discussions tend to be different with the different attendees. This can be difficult due to lack of budget and the Internet service not always being reliable at shows. We are thankful for the work of Philip Rothman and Peter Jonas in making video recordings of these meetings which get posted afterwards, but these do not allow for real-time interactive discussion.
Doug suggested that we have interim video face-to-face meetings using Zoom, which he would be willing to host.
Michael suggested possibly using a Slack channel or channels for ongoing chat discussion. There seemed to be many Slack users attending this meeting, so this seems worth investigating.
Daniel reminded the group that we have greatly reduced notifications from our GitHub repositories. So if you unsubscribed or filtered these notifications in past because there were too many of them, please reconsider as the notifications now go out only at key points like pull requests.
The co-chairs will be discussing these suggestions and plan to make proposals for more effective communication within the Community Group.
Later that evening, many of the attendees met for our 3rd annual dinner at Thai Nakorn restaurant in Garden Grove.
Attendees
Franck Duhamel, Arobas Music David Gros, Arobas Music Hans Landval Jakobsen, EarMaster Jason Freeman, Georgia Institute of Technology Asa Doyle, Hal Leonard Chris Koszuta, Hal Leonard Jeremy Sawruk, J.W. Pepper Doug LeBow, self Johannes Biglmaier, M3C Michael Good, MakeMusic Dominique Vandenneucker, MakeMusic Duncan Hearn, Musicnotes Jon Higgins, Musicnotes Steve Morell, NiceChart John Mlynczak, Noteflight Philip Rothman, NYC Music Services / Scoring Notes Eric Carraway, percuss.io Jennifer Amaya, Riverside City College Jeff Kellem, Slanted Hall Daniel Spreadbury, Steinberg Dominik Svoboda, self Pierre Rannou, Tutteo (Flat) Jan Vasina, self Fabrizio Ferrari, Virtual Sheet Music Kevin Weed, self
We are pleased to announce that a draft Community Report for SMuFL 1.3 has now been published, and we invite the Community Group to review the draft report so that we can move from draft status to a Final Community Report as soon as possible.
SMuFL 1.3 is the first release since the interim SMuFL 1.2 release in April 2016, which did not reach Community Report status. The main changes to SMuFL since the inception of the Community Group amount to the addition of some new ranges of characters – chief among them German organ tablature, Kahnotation dance notation, and supplemental ranges for clefs, chord symbols, octave lines, and time signatures – and the clarification of some aspects of the font metadata file specification.
You can view all of the issues that have been addressed in the SMuFL 1.3 Milestone on GitHub, and read a detailed list of changes in the Version History page in the specification itself.
Depending on the nature of the feedback received, we intend to advance from draft status to publishing a Final Community Report in around two weeks, aiming to publish in the week beginning 18 February 2019.
The W3C Music Notation Community Group will once again have a meeting and dinner at the NAMM Show in Anaheim, California. Both events are scheduled for Friday, January 25. The meeting will be from 3:00 pm to 5:00 pm in Room 201C of the Anaheim Convention Center. This meeting room is on the second level of the main building, between Peavey and Mackie. Dinner will be at 7:30 pm at Thai Nakorn at 12532 W. Garden Grove Blvd. in Garden Grove.
Because this year’s meeting is in the Anaheim Convention Center, you will need a NAMM badge in order to attend. Please let us know if you still need a NAMM badge. We are grateful to the staff of the NAMM Show for their help with providing both meeting space and badges.
To help us prepare for the meeting, please fill out this sign-up form if you plan to attend the meeting, the dinner, or both:
We will be discussing the current status and future plans for MNX, SMuFL, and MusicXML during this meeting. We look forward to seeing many of you there.
We are pleased to announce the appointment of Adrian Holovaty, CEO and founder of Soundslice, as co-chair of the W3C Music Notation Community Group, joining existing co-chairs Michael Good of MakeMusic and Daniel Spreadbury of Steinberg. Joe Berkovitz, founder and CEO of Noteflight and more recently of Risible LLC, is stepping down as co-chair.
We would like to express our deepest thanks to Joe for his contributions. Joe was instrumental in founding the Community Group and bringing MakeMusic and Steinberg to the W3C, showing them the benefits of developing MusicXML and SMuFL here. He has also been the driving force in the development of the MNX spec to this point.
After leaving Noteflight at the end of 2017, Joe has wanted to devote more of his time to both his artistic pursuits and family matters. After he indicated to the other co-chairs that he planned to step down, Michael and Daniel have been discussing how to keep the group’s efforts moving forward.
We are delighted that Adrian has agreed to help us drive MNX forward from here. Adrian has been an active member of the Community Group since its inception. He is not only the CEO of Soundslice but is also the co-creator of the Django Python framework. Adrian has invaluable experience in developing web-based music notation software and in shepherding large-scale projects. We are very fortunate to be able to call upon his expertise.
Although we believe most everybody in the community is already familiar with Adrian, we asked him to write a few words by way of introduction:
Hi everybody! Adrian here. I’m excited to play a bigger part in this community and help improve the lives of developers of music technologies around the world — and, most importantly, the musicians who use these technologies.
Professionally, I’ve been a full-time web developer since 2002. My largest contribution so far has been co-creating the open-source Django Web framework, used by many developers these days. I implemented much of the framework’s original code and helped build a thriving community of contributors.
Since 2012, I’ve been working full-time on Soundslice, a website that helps people learn and practice music. It has its own notation rendering engine and imports/exports various notation formats, so for better or worse I’ve acquired a deep technical knowledge of Western musical notation and tablature.
I live in Amsterdam and gig a few times a month with various gypsy-jazz bands. I also post videos of guitar performances to YouTube at youtube.com/adrianholovaty.
We can now turn our attentions to our plans for 2019. In the immediate term, we will publish the final community report for SMuFL 1.3 (the change in version number from 1.2 to 1.3 is merely symbolic, and no significant new development work beyond what has been done to date will be undertaken). We are also in the process of organising community meetings at the NAMM Show in Anaheim, California at the end of January and at Musikmesse in Frankfurt at the beginning of April.
Our goal for 2019 is to deliver a draft 1.0 version of the MNX-Common and MNX-Generic specifications by the end of the year. We believe that we have a solid foundation in terms of the basic musical structure for CWMN, and we will next turn our attention to some specific representation challenges before we then attempt to fit other MusicXML elements for specific notations into the framework. These specific representation challenges include:
How pitch should be encoded, and whether MNX-Common documents should always be in written pitch or sounding pitch.
How, or to what extent, MNX-Common documents should encode multiple presentations for the same musical material, e.g. the full score versus instrumental parts, and the differences between them, such as page and system breaks, differences in enharmonic spelling, information that should appear only in one or other presentation, and so on.
What the role of profiles will be in terms of specifying what aspects of MNX-Common will be supported by different types of applications, and how to manage user and developer expectation around these differences.
How should layout and performance data be represented in MNX-Common, and how should this interact with the semantic data.
Our medium-term goal is to present proposed solutions to these fundamental issues at our Community Group meeting at Musikmesse in April.
We welcome feedback from members of the Community Group about these changes and our plans for 2019. We look forward to hearing from you.
The W3C Music Notation Community Group met in the Symmetrie 3 room (Hall 8.1) at Messe Frankfurt during the 2018 Musikmesse trade show, on Thursday 12 April 2018 between 2:30 pm and 4:30 pm.
CG co-chairs Joe Berkovitz, Daniel Spreadbury, and Michael Good chaired the meeting, and over 30 members of the CG and interested guests attended. A complete list of the attendees is included at the end of this report. The presentations from the meeting are posted at
Peter Jonas from MuseScore recorded the meeting and has posted the video on YouTube. The video starting times for each part of the meeting are included in the headings below.
The noise in the background is from the Musikmesse. The audio improves significantly after 5:20 when the microphone is moved closer to the speakers.
MuseScore Sponsor Introduction (1:27)
MuseScore sponsored this year’s meeting reception. Daniel Ray describe how MuseScore was recently acquired by Ultimate Guitar. MuseScore will remain open source and free, but more resources are now available. MuseScore also wants to get more involved in standards activities and the community group.
Review Working Process to Date (2:40)
Daniel Spreadbury led a discussion of the current community group working process. Most of the discussion involved questions about using GitHub. Daniel Ray suggested that it would be good to share links for how to use GitHub. Joe Berkovitz suggested we should also do the same for Bikeshed, the tool that is used to maintain the MNX specification.
We also discussed the possibility of having more in-person meetings, either online or face-to-face. One way to do this might be to have meetings with specific themes. Daniel Ray suggested that in addition to themes based on portions of the spec, we could have themes based on specific use cases. This could tie in with other events – for instance, a meeting focus on music education and performing ensemble use cases at The Midwest Clinic. A conference like Midwest could get participation from composers, teachers, and performers in a way that the NAMM and Musikmesse conferences do not.
We also had a brief discussion of issues to suggest for active review in the near future. Alexander Plötz suggested addressing issues of transpositions and scores in concert or notated pitch. Daniel Ray asked about a timeline for the specification. Our goal is to have a draft version of the specification in early 2019, which is aggressive.
MNX-Generic (32:39)
Joe Berkovitz led a discussion and demonstration of the MNX-Generic, a notation format for generic music notation that coordinates SVG graphics with one or more performances. The demonstration begins at 39:22 in the video.
Discussion centered around synchronization and linking. These topics included synchronizing video as well as audio; synchronizing audio in music with repeat structures; and linking from MNX-Generic to a semantic format like MNX-Common.
Towards an MNX-Common Layout Model (1:14:39)
Joe Berkovitz led a discussion about whether is a possible or practical to standardize the layout of common Western music notation in a way that provides for better exchange between applications. This was one of the major requests to come from publishers during our NAMM meeting last January.
The presentation introduced some layout terminology and outline 5 different levels that we might take to standardizing layout:
The wild west
Explicit positioning
Explicit space requirements
Algorithmic space requirements
Algorithmic layout
The main point for discussion, besides clarifications of what was being proposed, was the reactions by group members to these proposals. Members of the group expressed several concerns.
Christof Schardt said “I think this is totally crazy!” because different applications have such different approaches to layout that bridging between individual applications and a standard layout algorithm would be very difficult. We could get a huge gain simply by making things more rigorous at the current level 2 (explicit positioning) and combining these improvements with MNX-Common’s improved musical data structures.
Reinhold Hoffmann mentioned that the publisher’s use case, where greater portability between applications is so important, is very different than the use case for his company’s everyday musician customers. It seems essential to have this available as an option for applications, not a requirement.
Adrian Holovaty mentioned the differences between capturing tweaks that an engraver has made, and the end results of a particular notation program’s algorithm. The former could be useful for his application when doing reflow, but the latter is something his application really doesn’t care about. Distinguishing these can be tricky though, especially for applications that might have sub-par rendering by default and require more manual adjustments than other applications.
Martin Marris mentioned that the tighter the spacing gets, the more that rules are violated and the more that discussions are overridden. When working for Henle and other classical publishers that prefer tight spacing, Martin is overriding the application’s defaults all the time. How can this type of constant adjustment be better preserved across applications?
Peter Jonas also asked about how to capture the differences between changes that are made for semantic vs aesthetic reasons.
Joe Berkovitz also related the history of CSS styling, which started with a smaller subset of styling features and grew more comprehensive over time. We do not need to take an all-or-nothing approach, but similarly start small and improve layout specification over time.
