The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases.
The Community Group documents, maintains and updates the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle a broader set of use cases and technologies, including use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML and SMuFL specifications.
The group is developing a new specification to embody this broader set of use cases and technologies, under the working title of MNX. The group is proposing the development of an additional new specification to provide a standard, machine-readable source of musical instrument data.
w3c/smuflGroup's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Slurs are now associated with events rather than
individual notes
Inner slurs are supported with an optional way
to specify individual note within the event at both the start and end of the
slur
Incomplete slurs are handled using the same approach
as incomplete ties.
This pull request also updates the MNX by Example page so slurs are associated with events. Adrian would like to also add examples for inner slurs and incomplete slurs. He will handwrite some simple examples and ask Michael or Daniel to engrave them for the visual examples.
NAMM
Michael will organize a dinner at NAMM for W3C Music Notation Community Group members and guests who wish to attend. The dinner will be held at Thai Nakorn in Garden Grove on Friday, January 17, at 7:30 pm. If you plan to attend, please fill out the sign-up form so we can reserve enough space.
Next meeting
The next co-chair meeting is scheduled for Tuesday 7 January 2020. We wish everyone a happy holiday season and new year!
Pull request #170, for making the <head> element optional, and pull request #171, specifying the approach to encoding barlines, have both been merged into the specification.
Slurs as liaison content
Pull request #169, concerning slurs as liaison content, has seen several new commits since the last meeting, and some good discussion with the community. The co-chairs discussed Adrian’s most recent proposal that slurs should be associated with the <event> element rather than the <note> element, though with the understanding that so-called “inner slurs” – where, for example, there are tied outer notes in a chord, and a slur between two notes in the middle of the tied chord must be indicated by drawing the slur directly next to those notes, rather than either above or below the whole chord – must be accommodated. The proposal for accommodating “inner slurs” is that each end of the slur may optionally refer to a note element by ID (using XML idref, which can be validated to the point that the ID is present in the document, though it cannot be validated to the point that the ID actually belongs to a note).
Furthermore, the co-chairs discussed the issue of incomplete slurs, for example when encoding a music example that either begins or ends with an incompletely specified slur (i.e. going to or coming from an unknown note). This situation is handled for ties, so the proposal is that the same technique should be extended to slurs as well.
There has also been some discussion (e.g. #167 and #169) concerning how MNX-Common can make it as straightforward as possible for consuming applications to determine which notes are under the slur, for example for the purposes of enhancing playback of slurred notes. The co-chairs discussed this and agreed that it is important for MNX-Common’s approach to encoding slurs should make the common case – where a slur starts and ends in the same voice – as straightforward as possible, but that it should not be expected to encode this directly, or to handle more difficult situations, such as a slur starting in one voice and ending in the other, where the boundary between the slur affecting one voice and the next is inherently unclear.
Ties in MNX-Common by example
Adrian has added a new Ties section to the MNX by Example page, showing how ties are specified in MNX-Common.
Dynamics
Issue #168 has been raised about the current specification for dynamics in the MNX-Common specification. The co-chairs discussed the proposal made by Peter Jonas (@shoogle) and they agree that the specification as it stands is probably too restrictive and does not reflect the richness of how dynamics are really used in CWMN, but more discussion and reflection is needed in this area. Daniel agreed to add some further comments based on the discussion in the meeting to the issue to encourage further discussion.
In-person meeting at The NAMM Show
There will be no official meeting of the W3C Music Notation Community Group meeting at the NAMM Show, but Michael will still organise a dinner for anybody who wishes to attend. Michael will share further details in due course.
Next meeting
The next co-chair meeting is scheduled for Tuesday 17 December 2019.
#171 specifies default barline treatment — as a shortcut for the common case of “display a normal barline after each bar, except for the final bar, which should get a final barline.”
Please comment there with feedback, even if you only want to give a thumbs-up emoji to express your support.
Adrian is planning to make one further improvement to #169: He’ll add a second slur example to the “MNX-Common by Example” document, showing how slurs-over-chords would work (which is worth providing an example for, given that a slur is attached to an individual note, begging the question “which note of the chord gets the slur?”).
MusicXML
Michael has done some catchup on the GitHub issue tracker lately. There’s been some discussion in various issues, and he’s planning to review the continuing discussion.
ISMIR report
Adrian gave a quick report about various notation-related projects he saw at the ISMIR conference last week:
partitura is a Python library for manipulating semantic music data, currently with support for MusicXML import. (Paper here.)
“A diff procedure for music score files” presented an algorithm for comparing two versions of a MusicXML file. (Paper here.)
“Visual pattern analysis using digital sheet music” detects musical patterns in MusicXML files. (Paper here.)
The Romantext Format is a “Flexible and Standard Method for Representing Roman Numeral Analyses.” (Paper here.)
Next meeting
The next co-chair meeting is scheduled for Tuesday 26 November 2019.
Following our last meeting, Adrian closed pull request #159 and opened issue #167 to cover converting slurs from using spanning elements to liaison content. He’ll now create a pull request to implement this in the spec, and seek community feedback on the pull request.
There was a wide-ranging discussion in issue #161 which were ultimately closed with no specific action required.
Jacques Menu opened issues #163 and #164, which were also ultimately closed with no specific action required.
Adrian has been engaging with the issues raised by Cecilio Salmeron in issue #160, and raised issues #166 (make the head element optional) and issues #165 (encoding policy for barlines).
The co-chairs discussed that we would like to encourage developers to include metadata, but in the spirit of keeping the format as slimmed-down and minimal as possible, it seems reasonable for the head element to be optional. Adrian will create a pull request for #166 to make the head element optional in the specification.
The co-chairs also discussed issue #165, and once again affirmed that we favour an “opt-out” approach for barlines, i.e. that normal barlines are assumed to be present unless they are explicitly encoded otherwise. Adrian will create a pull request for this issue to make this concrete in the specification.
Adrian also plans to work on a pull request for the wedge element in the near future, as discussed in previous meetings.
MusicXML 3.2
Michael has had some good discussions with the community concerning issue #295 for Roman numeral analysis. The discussion is in process and as yet Michael has not determined whether or not this will end up being in scope for MusicXML 3.2 depending on how complex it turns out to be to address the requirements in full.
SMuFL 1.4
Daniel has no update on SMuFL 1.4 this week.
In-person meetings in H1 2020
Michael has received his first enquiries about when and where in-person CG meetings are planned for 2020. As things stand, neither Daniel nor Adrian will be at the NAMM Show in Anaheim, CA in January 2020, though Michael will be there, so the co-chairs’ current thinking is that we may not have a formal meeting at NAMM in 2020, though Michael would be very happy to have individual meetings with CG members at the show.
The co-chairs still believe that an in-person meeting at Musikmesse from 1–4 April 2020 will be worthwhile, and we expect to poll the community about plans to attend in the near future.
ISMIR, November 2019
Adrian will be attending ISMIR next week in Amsterdam, and would be delighted to meet with anybody who has interest in the work of the Community Group who is attending the conference next week.
Music Engraving Conference at the Mozarteum, Salzburg, January 2020
A new conference called Music Engraving in the 21st Century will be taking place at the same time as the NAMM Show in Salzburg, Austria in January 2020. Daniel is planning to attend and Adrian may also attend. The co-chairs are interested to know whether sufficient members of the Community Group will be in attendance to warrant enquiring about holding a meeting at the conference.
Next meeting
The next co-chair meeting is scheduled for Tuesday 12 November 2019.
Pull request #158 for octave-shifts is now ready to go. Michael and Daniel have both reviewed the latest changes to the proposal, and agreed that this pull request can be merged. This pull request has now been merged.
Pull request #159 for slurs was prepared by Adrian but after discussion the co-chairs have agreed that, per Michael’s review of the pull request, we are not going to implement slurs as spanners but instead as liaison content, and a new pull request will be forthcoming taking this approach.
Following slurs, Adrian will look at fleshing out the specification for the wedge element, which can pull from the existing MusicXML definition of that element.
Issue #161 was opened by Bob Hamblok with the intention of starting discussion about the separation of concerns in MNX. The co-chairs had a brief discussion about this issue and arrived at the consensus that in fact the answers to the questions raised by Bob in this issue are settled already, and Adrian agreed to provide a response on behalf of the co-chairs.
Issue #160 was opened by Cecilio Salmeron concerning the MNX-Common by Example page. Adrian agreed that there is some mark-up fix-up required, and the co-chairs then discussed the issues concerning barlines. They agreed to open an issue concerning the treatment of barlines in MNX-Common, with the initial proposal that systemic barlines do not need to be encoded in the semantic sense, since they are presentational, and nor do regular barlines between measure elements. MusicXML has the default that the final barline in a document would be a normal barline unless otherwise specified, but the co-chairs propose that the final barline in a document would be a final barline unless otherwise specified. Adrian will provide a response to the other points raised by Cecilio in due course.
MusicXML 3.2
Michael opened issue #294 for the proposed listen element in MusicXML 3.2, and there has been some good initial discussion. Michael will respond to the existing discussion.
Issue #295 has also been opened concerning Roman numeral analysis in the existing MusicXML specification, a little-used feature; in fact, Michael believes no developer has ever implemented this feature before. Michael will assess this issue as soon as possible to determine whether any changes in documentation or specification should be made for MusicXML 3.2.
SMuFL 1.4
Daniel has not yet had a chance to do any new work on SMuFL 1.4 but the co-chairs reviewed issue #114 (half-harmonic noteheads) and agreed that it should be in scope for version 1.4.
Next meeting
The next co-chair meeting will be on Tuesday 29 October 2019.
Daniel Spreadbury was unable to attend this meeting, but Adrian Holovaty and Michael Good discussed several issues in his absence.
Octave shifts in MNX-Common
Adrian has updated pull request 158 to clarify the language in response to earlier comments. We plan to merge after co-chair review.
Slurs in MNX-Common
Adrian has created pull request 159 to add slurs to the MNX-Common spec and the MNX-Common By Example page. We discussed several issues regarding this pull request which will be added as review comments.
MusicXML 3.2 update
Michael reported that the idea for a <listen> element for score following and machine listening applications was supported by Antescofo as well as MakeMusic developers. With this expression of cross-application interest, Michael will write this up as an issue for MusicXML 3.2. Although larger in scope than most MusicXML 3.2 issues, it is something that seems to fit into the existing MusicXML 3.1 design, rather than relying on the new features in MNX-Common.
In reviewing the MusicXML 3.2 issue list, we have added an MNX label to several issues that we plan to defer to MNX-Common. We will now plan to close these issues, after making sure the issue is either addressed in the current MNX-Common spec or in an MNX issue. We will add a link to the relevant MNX location in a comment while closing each issue.
Adrian had a question about how to represent drum tablature in MusicXML which he will enter as a new MusicXML issue.
Next meeting
The next meeting of the co-chairs is scheduled for October 8, 2019.
We have so far only had one comment on pull request #158, concerning a request to be more precise about the effect the octave-shift element has on both written and sounding pitch. It can be argued that the direction of the octave-shift could go either way, and so the co-chairs have decided to go with the same direction used in MusicXML. We think it might be worth having a separate discussion of the direction of the octave-shift in the spec. We will remove the description “true pitch value” to avoid any ambiguity about the effect on the written and sounding pitch. We are not going to revisit the more general definition of pitch for MNX-Common in connection with this pull request, though we do not rule it out for the future.
Adrian will make a few last changes to the pull request, and Michael and Daniel will review before the pull request is merged.
Spanning directions
Adrian is still working on more definitions for spanning directions for inclusion in the MNX-Common specification and the MNX-Common by Example page, which he hopes to have working soon.
MusicXML 3.2 update
Michael has added issue #293 to cover the requirement of describing changes in sound for virtual instruments. There are currently 28 issues in the MusicXML 3.2 milestone for consideration, and sorted into general categories of issues to work on next.
SMuFL 1.4 update
Daniel has not been able to devote any time to SMuFL 1.4 recently in the run-up to his recent product release but still anticipates being able to complete the work required for SMuFL 1.4 before the end of the calendar year.
Next meeting
The next meeting of the co-chairs is scheduled for September 24, 2019.
Adrian has been working on how octave shifts should be handled in MNX-Common, and has prepared a pull request #158 to address issue #111, which covers both the specification for and examples of the proposed octave-shift element. The co-chairs welcome feedback from the community about this new specification element. You can view the updated MNX-Common by Example file without checking out the branch here.
If you have any comments about this proposed change, please leave a comment in the pull request.
Adrian plans to continue work on spanning elements since he has now got a good feel of the issues these notations present, which will address issue #114 among others. He also plans to add a further example for the octave-shift element that applies only to a single voice or sequence.
MusicXML 3.2 and SMuFL 1.4
Michael and Daniel did not have any updates on the MusicXML 3.2 or SMuFL 1.4 projects for this meeting.
Next meeting
The next co-chair meeting will be on Tuesday 10 September.
Adrian has added a section on time signatures to the MNX-Common by Example page to illustrate the approach MNX-Common takes to time signatures, showing how time signatures are shown in the global element. The co-chairs discussed whether or not we should include the optional index attribute to each measure element that makes the bar number explicit, but decided to keep it as simple as possible for the purposes of this example.
The co-chairs discussed the issue of multi-metric music, which requires multiple global elements and the assigning of specific parts to the time signatures in each global element. There was also further discussion of whether index should be compulsory, which would enable a sparse representation of the global element, i.e. only including those measure elements in which there is a change of time signature, but this would require making index compulsory and it was decided not to revisit this prior decision again now.
Octave lines
Adrian is next going to look at giving examples of octave lines in MusicXML. Octave lines are an example of a spanning element, which appear either in the directions attribute of a measure element (if they apply to all voices) or of a sequence attribute (if they apply to a specific voice). We need to be clear about the end attribute and whether or not the note or event at that position is transposed by the octave line.
Adrian will work up an example for discussion and then move to adding octave lines to the spec. This will be relevant to issue #111.
MusicXML 3.2 and SMuFL 1.4 update
There was no discussion of MusicXML 3.2 or SMuFL 1.4 in this meeting.
Next meeting
The next co-chair meeting will be on 27 August 2019.
The MNX-Common and MNX-Generic specs have now been split and the pull request merged back to the master branch. The MNX-Common by Example page is also now part of the main MNX-Common repository and is linked to from the main page. This closes issue #98.
Issues under Active Review
Next on Adrian’s list is to pick one of the issues currently under Active Review and to flesh out a proposal by adding more information to the MNX-Common by Example page.
MusicXML 3.2 update
Michael has not made any specific progress on the MusicXML 3.2 specification issues since the last meeting.
SMuFL 1.4 update
Daniel has not made any specific progress on the SMuFL 1.4 issues since the last meeting.
Next meeting
The co-chairs will next meet on Tuesday 13 August 2019.
w3c/smufl
