Skip to toolbar

Community & Business Groups

Music Notation Community Group

The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases.

The Community Group documents, maintains and updates the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle a broader set of use cases and technologies, including use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML and SMuFL specifications.

The group is developing a new specification to embody this broader set of use cases and technologies, under the working title of MNX. The group is proposing the development of an additional new specification to provide a standard, machine-readable source of musical instrument data.

w3c/musicxml w3c/mnx w3c/smufl

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.

final reports / licensing info

date name commitments
MusicXML Version 3.1 Licensing commitments
SMuFL 1.3 Licensing commitments
SMuFL 1.4 Licensing commitments
MusicXML 4.0 Licensing commitments

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Publish Reports

Co-chair meeting minutes: March 15, 2022

In-person Community Group meetings

It was recently announced that Musikmesse 2022, which had been scheduled for 29 April–1 May 2022, has been cancelled, and the B2B part of the fair has been cancelled permanently. The co-chairs are considering some alternative events and conferences that might possibly be a future home for our in-person meetings in Europe:

  • Open source: FOSDEM, normally in Brussels in February.
  • W3C: TPAC, which rotates around the world, and in 2022 is expected to be in Vancouver, Canada, and it’s not clear when it will next be in Europe.
  • Music librarians: MOLA Conference in June, this year in Philadelphia, USA; in Berlin, Germany in 2023.

We could also consider meeting at IRCAM in Paris, or at Steinberg’s headquarters in Hamburg.

We welcome any further suggestions of events, conferences or organisations that could host our in-person meetings, and feedback on whether any of the above would be preferable.


Adrian has created pull request #282 to cover the proposal for styling attributes in issue #263, and welcomes feedback. Adrian has written a synopsis in the pull request itself as an introduction, and invites the community to digest the pull request and provide further feedback.

Adrian will next turn his attention to developing a proposal for how to handle the differences between full scores and instrumental parts, for issue #34.


Daniel has started some initial work on SMuFL 1.5, with the intention of producing a new revision of the specification by the end of 2022. He has created a SMuFL 1.5 milestone on GitHub and has reviewed all of the existing open issues, assigning 30 of the 48 open issues to that milestone for consideration and potentially implementation. An updated set of labels has also been added, and these labels have been applied to the existing issues.

Daniel has also decided to use mdBook instead of GitBook to produce future versions of the specification, and the current editor’s draft is now using the new mdBook output. mdBook is more lightweight than GitBook, has a better author-test-publish workflow than GitBook, and produces output with a better user experience, including enhanced search.

One of the issues that we hope to address in the next revision is #214, to provide translations for the human-readable names in the glyphnames.json and ranges.json SMuFL metadata files. The co-chairs are currently evaluating a pair of online translation management tools (Transifex and POEditor), both of which provide a free service to open source projects.

We have also enabled the GitHub Discussions area for any questions about how to use SMuFL, announcements about any new software that implements SMuFL support, and so on. Please feel free to make use of this new discussion platform.

If you have any issues that you would like to be considered for inclusion in SMuFL 1.5, please ensure they have been raised on GitHub as soon as possible so that we can start to bring the scope of the new version into focus.

Next meeting

The next co-chairs’ meeting will be on Tuesday 29 March 2022.

Co-chair meeting minutes: March 1, 2022

MusicXML 4.0

We have now implemented the GitHub Discussions feature for the MusicXML repository as agreed at the last co-chair meeting. If you have any questions about MusicXML, or any announcements about products adding support for MusicXML, please make use of the Discussions area on GitHub.


Pull request #281 (for issue #185), for the specification of layouts, has now been merged. Issue #263, concerning the proposal for the infrastructure for styling, is now ready to be formalised into a pull request. After this proposal has been merged into the specification, separate issues to cover the specifics of defining the various styles that can be applied to elements in MNX documents will be added; Adrian proposes adding a single style property to the specification so that there is a fully worked-out example.

Following that work, the next area to be tackled, as previously discussed, will be for dealing with the differences between scores and parts, in particular things like note spelling, as covered by issue #34.

Next meeting

The next co-chairs’ meeting will be on Tuesday 15 March 2022.

Co-chair meeting: February 15, 2022


We have decided to enable the Discussions feature on GitHub for the MusicXML repository. This is intended to be a place for questions about MusicXML, but not bug reports in the specification or documentation, or proposals for new features: those should still be raised as issues, as before. Several issues that have been raised recently would actually have been better served as discussions, and so we hope that this will prove to be a useful resource for the developer and user community.


Adrian has integrated some further changes in pull request #281 for issue #185, addressing feedback from community members to ensure that the examples and the specification match, and renaming a couple of the elements specified. We anticipate the pull request will be merged within the next few days.

The next area of work is going to be producing some examples in support of issue #263 to bring the proposal for styling towards a pull request. We hope that producing some concrete examples of these new properties in action will help other community members assess the overall proposal and give further feedback.

Next meeting

The next co-chairs’ meeting will be on Tuesday 1 March 2022.

Co-chair meeting: February 2, 2022

In-person Community Group meetings

It appears unlikely that we will be able to plan to get together at an in-person event this coming spring. There is still uncertainty over whether events like Musikmesse in Frankfurt and The NAMM Show in Anaheim will occur as currently planned, and it appears that logistically not all of the co-chairs will be able to attend either of these events in any case. Other potential opportunities for an in-person meeting in the spring present similar challenges.

Therefore the co-chairs propose that we will continue to meet online this year. Our last community group meeting was in October, so our current thinking is that we will plan for an online community group meeting in the autumn.

It may be that one or more of the co-chairs is in attendance at either Musikmesse or The NAMM Show, and if so, we will aim to arrange a social gathering for any community group members who are also in attendance.


Pull request #281 has been prepared by Adrian to bring the staff and system layout changes proposed in issue #185 into the specification. Christina Noel has prepared a set of music examples that demonstrate these new features in action, which you can find here. We are currently gathering feedback on the pull request and certainly welcome further feedback from community members who may not have yet had the opportunity to review the changes. The co-chairs request that any further feedback is submitted on the pull request itself by the end of this coming Friday, 4 February 2022.

Following the merging of this issue, we will turn our attention to the proposal for styling in issue #263. The best way to get familiar with the current state of this proposal is to read Joe Berkovitz’s comment from 3 December 2021.

Next meeting

The next co-chairs’ meeting will be on Tuesday 15 February 2022.

Co-chair meeting: January 18, 2022

Group Charter update

The updated Group Charter comes into effect today, following the completion of the election on 9 January 2022. The proposed update passed by a margin of 24 votes for to 0 votes against.

The community group wiki will be further updated with a link to the two previous versions of the charter and the election results in due course.


Adrian has been working on pulling together the changes proposed for issue #185. The current status of this work is that there is a new top-level layouts container element. The next step is to develop a series of examples to demonstrate this element, and these will be coming soon.

The next area of work will be to focus on the proposal for style properties described in issue #263. If you would like to get an overview of this proposal, Joe Berkovitz’s comment here provides a synopsis.

Instrument data

Now that the updated Group Charter is in effect, we can begin the formal work on the instrument data project. Daniel will work on an initial list of requirements as a starting point for discussion and share at the next meeting, all being well.

Next meeting

The next co-chair meeting will be on Tuesday 1 February 2022.

Co-chair meeting: January 4, 2022

Group Charter update

The election concerning the revised charter for the Community Group ends at 2300 UTC on Sunday 9 January 2022.

If you have not yet cast your vote for or against the charter update, please go to the Charter Election page on the group wiki to do so. Once you are at the election page:

  • If you don’t see any Edit options, log in to your W3C account by clicking Log in in the upper right corner of the page. You created a W3C account when joining the Music Notation Community Group.
  • Click on the “edit” link in the appropriate Votes section to add your Yes or No vote. Please put your name on a separate line in the bulleted list.

If you find you cannot log into your W3C account or have other problems editing the wiki page to cast your vote, you may also cast your vote on the public-music-notation-contrib mailing list. One of the co-chairs will then transfer your vote to the wiki election page.


Adrian has updated the mnxconverter and its test cases to use the new element names that were decided upon for #265.

Adrian also plans to publish a pull request addressing the proposals for grouping parts described in issue #185 for discussion and approval. If any members want to read a summary of the proposal ahead of the pull request’s publication, they can read this comment from Christina Noel on the issue.

Next meeting

The next co-chairs’ meeting will take place on Tuesday 18 January 2022.

Co-chair meeting: December 7, 2021

Community Group Charter update

After the publication of the draft of the revised Community Group Charter, we received some proposed amendments from James Ingram, for which the co-chairs are grateful. Michael made some amendments in response to these proposals. The proposed Group Charter can be read here.

The co-chairs now propose that we begin the 30-day election period for the approval of the revised Group Charter this Thursday 9 December 2021. The election will conclude on at 23:00 UTC on Sunday 9 January 2022. The method for voting will be to register your approval or disapproval on a dedicated page on the Community Group Wiki. If for any reason you are unable to sign in to the Wiki but still wish to vote, you can alternatively register your vote via the public-music-notation-contrib mailing list. Michael will send full instructions for how to vote at the beginning of the election period on Thursday 9 December.


Adrian has completed the migration of the last details of the old specification to the new specification, together with a list of the details that have intentionally not been migrated to the new specification (in the first section of the old specification document, Status of this document). This closes issues #253 and #223.

Issue #265 is also now closed: a number of elements with similar names in different contexts have now been renamed to avoid problems when validating against the W3C XML Schema. The following elements have been renamed:

  • <directions> (global) is now <directions-global>
  • <directions> (part) is now <directions-part>
  • <directions> (sequence) remains <directions>
  • <measure> (global) is now <measure-global>
  • <measure> (part) remains <measure>

The MNX converter has yet to be updated to conform to these latest changes, but Adrian plans to do that imminently.

Issue #266 has also been addressed, clarifying that <score> elements can use <layout> elements without requiring any <page> elements, to satisfy use cases where you need to describe a layout but no specific page information is required, for example to produce a single system of unspecified width (like Finale’s Scroll View).

We have now reached consensus on the long-standing issue concerning the grouping of parts (issue #185), and thanks to the work of Christina Noel to summarise the consensus view, Adrian will now prepare a pull request to work this into the specification.

In line with the revised Group Charter, the co-chairs have closed the remaining issues related to the proposed MNX-Generic format, since that is not within the scope of the community group’s work. As a corollary, we have also decided to remove the MNX-Common tag from the GitHub issues, since all open issues in the MNX project relate to what is now known simply as MNX.

Next meeting

The next co-chairs’ meeting will be on Tuesday 4 January 2022.

Co-chair meeting: November 22, 2021

Group charter update

Michael has produced a draft of the updated Community Group charter that is now ready for review, which you can read here. If you want to compare the revised version with the current version, you can click here. The revisions extend the scope of the Community Group’s work to include the proposed new musical instrument data project, updating the description of the MNX specification to reflect the current status, updated information about the deliverables produced by the Community Group, and made some smaller edits that reflect the current working practices of the group.

To comment on the revised charter, please send an email to the public-music-notation-contrib mailing list (archives here). We apologise in advance for the higher than usual traffic on this mailing list, but this is a crucial step in the work of the community group, so we ask for your forbearance.

Please make any comments about the proposed revisions via the mailing list by Monday 6 December 2021. We plan to start the 30-day election process to approve the revised charter later that week, with the aim of having the revised charter approved early in January 2022.


A proposal for uniform style properties for MNX has been put forward by Joe Berkovitz (issue #263) that has generated some excellent feedback, and since this is an area of particular importance it would be great to have more contributions from other group members.

Another issue that has been actively discussed recently concerns re-use of element names in different contexts (issue #265): it appears that this will be not only potentially confusing but will also present serious obstacles for code-generation based on the XML schema. The proposed solution is to rename the elements, and Adrian will put forwards a concrete proposal.

Adrian continues to make progress on the project to audit the old specification document to bring things over to the new specification (issue #253), and to build a list of elements proposed in the original specification that are insufficiently concrete to be moved over as-is, or have been decided not to be done in MNX 1.0. Adrian is close to completing this task now.

Musical instrument data

Michael and Daniel met last week with Jeremy Sawruk and Simon Smith, who have expressed an interest in co-editing the proposed musical instrument data specification that is currently under discussion. The co-chairs would still welcome hearing from anybody who would be interested in taking on any part of the responsibilities for editing this specification, or potentially helping out in ancillary ways such as building software tools to manage and marshall the required data. If you might be interested, please contact Daniel via email.

The project cannot move forwards formally until the charter revision has been approved, but assuming it does so, the plan will be to bring together the co-chairs and the parties interested in playing a role in co-editing the specification together to start drafting a set of use cases that can be discussed by the wider community group and which will eventually form the basis of scoping the new project.

Date of next meeting

The next co-chairs’ meeting will be on Tuesday 7 December 2021.

Co-chair meeting: November 9, 2021

Community Group Charter revision

Michael’s current plan for revising the Community Group Charter is to create a new page for the revised Charter in the wiki, starting with the existing Charter and then revising it on the wiki so that there is a good audit trail for the changes.

Approving the Charter requires an election process and requires a two-thirds majority of votes cast to secure the approval. The co-chairs are considering how to conduct this election and are considering using the wiki for the election process as well.

Michael aims to complete the process of revising the Charter, including the 30-day election process, by early January 2022.


There has been a lot of discussion on a wide variety of issues since the Community Group meeting.

Adrian has already brought over a number of the algorithms from the original specification into the new specification, and aims to bring over the remaining small details from the original specification to the new one by 12 November, so that the old specification can be properly deprecated. As part of this process, Adrian has implemented some changes to the docgenerator tool to allow nicer formatting of the algorithms that are used to describe the micro-syntaxes in the specification.

Adrian is also devoting some time to tending to the open issues and in particular to breaking down larger issues into more atomic, actionable ones, in the service of moving towards a definitive list of tasks for the version 1.0 specification milestone.

We are also interested in exploring the use of GitHub Discussions as a means of allowing more detailed discussion that spans multiple issues. Adrian will look in more detail at the capabilities of the Discussions feature and determine whether or not it seems suitable for our use.

The default branch in the MNX repository has been renamed to main (issue #233).

Instrument data

The proposal that the Community Group should take on an additional project of building a database of structured data about musical instruments was received enthusiastically at the most recent meeting. The first step towards this is to update the Charter to include this project as within the scope of the Community Group’s areas of work, which Michael is taking care of.

Two people have so far expressed an interest in becoming editor or co-editor of the new specification. The co-chairs will schedule meetings with these people to explore this further soon.

In the meantime, if any other group members are interested in taking on the role of editor or co-editor, please let the co-chairs know.

Next meeting

The next co-chairs’ meeting will be on Monday 22 November 2021.

2021 Community Group Meeting Minutes

As part of the W3C TPAC 2021 conference, the W3C Music Notation Community Group held a virtual meeting via Zoom on 28 October 2021, its first meeting for all group members since April 2020.

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 there is also a complete transcript available via closed captioning. The video starting times for each part of the meeting are included in the headings below.

The chat log is available here:


The following people attended the meeting via Zoom:

  • Michael Good, MakeMusic (co-chair)
  • Adrian Holovaty, Soundslice (co-chair)
  • Daniel Spreadbury, Steinberg (co-chair)
  • Douglas Blumeyer
  • Chris Cianflone, MakeMusic
  • Cyril Coutelier, Flat
  • Jim DeLaHunt
  • Roger Firman, Golden Chord
  • Mark Green, MakeMusic
  • Bob Hamblok
  • Andrew Hankinson, Oxford University
  • Marco Herrera-Rendon, MakeMusic
  • Dominik Hörnel, capella-software
  • Reinhold Hoffmann, Notation Software
  • Kazuhiro Hoya, Japan Commercial Broadcasters Association
  • James Ingram
  • Peter Jonas, MuseScore
  • Martin Keary, MuseScore
  • Jeff Kellem, Slanted Hall
  • Steve Lee, W3C
  • Christina Noel, Musicnotes
  • Cecilio Salmeron
  • Jeremy Sawruk
  • Rachel Yager

Introduction to the Music Notation CG (3:25)

Michael Good began with a short introduction to the work of the W3C Music Notation Community Group, and the pre-existing specifications that were brought under the auspices of the CG when it was formed in 2015, MusicXML and SMuFL.

Douglas Blumeyer asked about where the CG activity is happening. Christina Noel replied that if you want to get involved in the activities of the group, the majority of that activity is happening in the GitHub repositories for the main specifications.

Progress update since last meeting

Each of the co-chairs provided an update on the current projects undertaken by the Community Group.

MusicXML 4.0 (12:23)

Michael provided a brief overview of the new features and improvements in MusicXML 4.0, which was released in June 2021. Michael expressed his particular pleasure and pride in the revised MusicXML documentation, which has been wanted by the software development community for 20 years, and which will be of huge benefit to developers in the future. Many of the other improvements are very beneficial, particularly in handling scores written in concert pitch while retaining instrumental parts in transposed pitch. Machine listening features that will benefit applications like SmartMusic, Antescofo, Metronaut, etc. have also been a focus.

There are no current plans for MusicXML 4.1, but community group members are welcome to submit ideas and requirements by creating new issues in GitHub.

SMuFL 1.4 (20:06)

Daniel provided a brief update on the new version of SMuFL, version 1.4, that was completed in March 2021. No work on SMuFL 1.5 is currently ongoing, but it is hoped that work will begin in the first half of 2022. The focus for that release is not yet determined, but the expectation is that it will be focused on further enrichment of the font-specific metadata format, particularly with regard to management and meaning of optional glyphs.

Mark Green asked whether any consideration had been given to adding information to the font-specific metadata for the SMuFL version of specification a font conforms to. Daniel recommended that Mark raise this as an issue in the GitHub repository and that it would be considered for implementation in SMuFL 1.5.

Documentation generator for MusicXML and MNX (30:13)

Adrian talked about the reasons why he decided to build a new document generation tool to provide high-quality specification documentation for both MusicXML, which had been using documentation from an old version of Madcap Flare, and MNX, which had been using the Bikeshed specification generator.

Adrian built a new platform on top of the Django framework that allows you to run a locally-hosted web application to enter the structured data about the elements, attributes and data types in an XML-based specification, and then generate a complete web site for the specification.

The document generator system has a good deal of infrastructure around providing structured examples for the format being documented, so that all of the elements and attributes in the example are cross-linked to the relevant documentation.

Steve Lee asked whether he could get the URL for the example provided in the spec. Adrian explained that every element has its own permanent URL.

James Ingram asked whether it would be possible to add code folding to the examples. Adrian said that he thought this was a good idea, and could be implemented, with the only reservation that the highlighted markup for a particular example would probably need to be always expanded.

Ongoing work

MNX specification update (39:03)

Adrian talked about the ongoing work on the MNX specification, and in particular the large amount of work that went into the transition of the old Bikeshed-based spec into the new documentation tool.

Adrian outlined the benefits of MNX’s design, and in particular its desire to be highly semantic and with a clean separation between musical content and presentational or styling information. The format that is emerging is indeed strongly focused on semantics, and as a group we are navigating these sometimes tricky grey areas quite successfully.

The philosophy for developing MNX is to be example-driven, and pages like the comparison between MNX and MusicXML encoding are a strong focus for the development work. Michael stepped in to say that some of MNX’s design decisions make the format much more suitable for use as a native format for music notation applications than MusicXML, which is one of the strong benefits of the new format over MusicXML.

As a demonstration of the power of the semantic-driven approach being taken for MNX, Adrian showed a page of music in which music for multiple players are condensed down onto a single staff, something which is not easily possible in MusicXML, at least not taking a semantic approach. MNX, however, makes this possible by encoding the part elements (i.e. the music for each player) separately, and then there can be multiple separate score elements that are effectively a rendering of the semantic parts into a particular layout, determining the allocation of parts to staves. There are still some tension points to be resolved in this area, and Christina Noel and James Ingram appealed to other members of the community to join in this work.

The next steps with MNX are to put together the definitive list of remaining work for MNX 1.0 by assigning issues to the 1.0 milestone.

Jim DeLaHunt asked whether the MNX Converter project is one-way or two-way: currently it’s one-way (MusicXML to MNX), but Adrian expressed a willingness to make this two-way in future.

Steve Lee, as a new member to the group, asked about the plans for MNX, as to whether it is envisioned as a successor to MusicXML, and how we plan to get buy-in from software developers. Adrian replied that yes, it should ideally become the successor to MusicXML, and Christina Noel expressed that Musicnotes is already looking into supporting it. Adrian also expressed that he would draw upon Michael’s experience in building adoption for MusicXML.

Adrian also recommended that anybody interested in following the work on MNX should follow the blog and sign up for the public-music-notation-contrib mailing list.

Reinhold Hoffmann asked for an estimation of the realistic timeline for when MNX 1.0 might be ready. Adrian replied that there would probably be no down-side to starting implementation now, since the existing parts of the stable are considered to be stable. Reinhold clarified that he is interested in knowing when there will be sufficient momentum behind the format to cause multiple companies to decide to allocate resources to implementing the format. Adrian replied that this is really a difficult question to answer in general because every company’s priorities and level of resourcing are different. Michael suggested that, based on his experience with MusicXML, which took off once it reached version 1.0, that might be a good point to really determine the point at which it makes sense to start working on MNX implementations.

New possibilities for community group work

Instrument data (1:10:40)

Daniel talked about 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.

This idea was met with enthusiasm by the group, and several members immediately started sharing ideas and possible data sources to help get the project off the ground, including suggestions to reach out to musicologists, to the Musical Instrument Museums Online organisation, to refer to the existing taxonomy of more than 1000 instruments provided by Musicbrainz, and more. Mark Green suggested that it would be great to be able to include pictures (perhaps icons, photos, line drawings) of each instrument, and that localisation (of names, playing techniques, etc.) could also be valuable.

The co-chairs agreed that they will discuss this proposal some more, do some further research, and report back to the community group.

Non-Western music notation (1:27:31)

The group is not restricted by charter to focus purely on Western music notation, but the co-chairs feel that the current community group members don’t possess the necessary expertise to be able to develop formats for non-Western notation formats.

James Ingram says that he feels that once MNX 1.0 is complete, we may well find that support for some other notations, such as Asian notation systems, are reasonably close to Western tablature, and that the parallels between these notations might mean that some of the work has been done. Michael pointed out that the group’s work is guided by need and demand expressed by the group, so we do not necessarily have a strong long-term plan that already takes in these notations, but we remain open to the possibility of working on it in future if the demand emerges.

Updating the group charter (1:33:09)

Michael outlined the current state of the Community Group charter, which has not been significantly updated since the inception of the group in 2015. As the work on MNX has developed, some of the existing information in the charter has become outdated, and the co-chairs propose revising it.

Peter Jonas expressed surprise that the charter is sufficiently focused that it could go out of date. Michael explained that the original charter was drafted by original co-chair Joe Berkovitz, and that he had brought his experience as chair of the W3C Web Audio Working Group to bear on the process of drafting the charter. Michael pointed out that it’s common for both community and working groups to go through a process of re-chartering.

Michael has volunteered to take the lead on revising the charter and will report back to the group in due course.

Planning for in-person meetings (1:38:01)

Michael outlined the next possibilities for when we might be able to get together again in person, with the proposal that we would resume in-person meetings along with Zoom meetings. Spring 2022 provides four strong possibilities for in-person events:

  • Musikmesse, Frankfurt, Germany (29 April-1 May 2022)
  • The NAMM Show, Anaheim, CA (3-5 June 2022)
  • TENOR Conference, Marseille, France (9-11 May 2022)
  • Music Encoding Conference, Halifax, Canada (19-22 May 2022)

These events represent a balance between industry events and academic conferences, and Michael asked for feedback from the group about any preferences.

Mark Green asked whether it is typically possible to have virtual attendance at these in-person meetings, and Michael explained that this is not usually the case because the network facilities at these kinds of events tend not to be too good.

Jim DeLaHunt expressed his desire to see stronger cooperation between the W3C Music Notation Community Group and the MEI community, and perhaps setting up a meeting at the Music Encoding Conference would be a good opportunity to do that.

Q&A (1:47:05)

Jim DeLaHunt asked about converters between MNX and MEI, and wondered whether it might be possible to include MEI in the MNX by Example page. Michael cautioned that since there are hundreds of existing formats out there, and we might not be able to do a great job of managing examples in lots of other formats, and proposed that we in the community group ought to focus on our own formats. Adrian agreed that it would certainly be good to see the MNX Converter project become more powerful.

Meeting closed (1:52:01)

Michael closed the meeting by thanking everybody for their participation and provided links to how to join the group for any participants who are not already members of the group, and how to follow the specific GitHub repositories for each of the active projects.