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.
Adrian has created the necessary staff position data type for position on staff, and has updated clefs to use this new staff position data type, and similarly updated both the MNX converter and all of the MNX examples (issue #315).
The next steps are to consider how to encode the staff positions of unpitched notes (issue #316), and how to position the staff positions of rests (issue #318). We agreed that in normal single-voice sequences, rest staff positions do not need to be encoded, and we will provide tables (possibly both in the speicifcation and in structured data) providing the nominal positions of rests, based on the origin points of the rest glyphs in the SMuFL specification: for example, a half rest (minim) would have position 0, and a whole rest (semibreve) would have position 2. We agreed that for multiple voices in the same measure, it would be advisable to encode the position of every rest.
Adrian also plans to add support for grace notes to the MNX converter in the near future.
We agreed that we will incorporate the proposed extensions to MusicXML sound IDs for marching percussion proposed by Zac Jansheski (issue #494) in the MusicXML 4.1 release.
The next co-chairs’ meeting is scheduled for Thursday 7 December.
Adrian has made the changes for issues #313 and #314 for the encoding of positions within a bar and clef positions. Changes have been made to both the MNX specification and the MNX examples.
Adrian has also been working on the MNX converter. He’s updated the converter to handle the change in how sequences are encoded in the new top-level sequences object. Clefs, including inner-bar clef changes, are also now handled in the MNX converter, along with a new test case for clefs in MusicXML. Adrian has also improved the error handling in the MNX converter, showing a descriptive error message rather than the Python traceback. Based on a suggestion from Mogens Lundholm (issue #3), errors for invalid elements in MusicXML file now show the line number of the invalid entry. Next, Adrian plans to implement grace notes in the MNX converter (issue #7).
We discussed how to encode unpitched notes (issue #316), and came to the consensus that we should encode unpitched material using staff position rather than relative to a specific clef. Adrian will work this up into a formal proposal shortly.
Finally, and further to our last meeting, we discussed the community feedback on the numbering of staff positions (issue #315), and agreed that we will proceed as described. We decided that we would assume that when we come to describe the distances between staff lines, we would limit them to integral values as multiples of this staff position unit (which can be thought of as half a space, or half a standard notehead’s height).
The next co-chairs’ meeting will be on Thursday 24 November 2023.
We briefly discussed the proposal in issue #494 from @zacjansheski to extend the list of sound IDs to more specifically encode the sound quality of marching percussion instruments, and agreed that this would be a good change.
Following our discussion in our last meeting about issue #314 for a unified way of encoding rhythmic position, there has been no feedback from the community dissenting against this change, so in the interest of keeping moving forwards, Adrian will write up the required specification change to implement this, and then update the MNX Converter to handle clef changes in the light of this improvement.
Next, Adrian plans to run a bunch of MusicXML files through the MNX Converter to identify which kinds of notations are not yet at all handled and set our next priorities.
Adrian also plans to start looking at the automatic generation of a JSON Schema from the docs generator and specification, and will use the example schema developed by Paul Overell in pull request #308 as the basis to check that the generated schema matches well enough.
We briefly discussed issue #294 concerning the JSON representation of rests, and in particular how the vertical position of the rest should be encoded. We have decided to proceed with the encoding of rests as described in this issue, so will close that issue, and have opened issue #315 to discuss the approach towards encoding the vertical position of non-pitched items on staves, including rests and clefs (which will require some rework in the light of this change).
The next co-chairs’ meeting is scheduled for Thursday 9 November.
Following on from our last meeting discussing ways of defining fully-qualified positions for items in bars, Adrian has created issue #314 and we welcome community feedback on how we might approach this. Since Myke was back this week, we spent much of the meeting discussing this issue in more detail, and by the end of the meeting had settled on an enhanced version of the original proposal, to add information about the voice to which the grace note index applies. Adrian has added this as a comment to the issue.
Myke also plans to start looking at some of the (hopefully) less controversial MusicXML encodings for items like chord symbols, figured bass, Roman numeral harmony analysis, direction, and technical, and to start considering how some of these might be easily ported across to MNX and expressed in JSON rather than in XML.
The next co-chairs’ meeting will be on Tuesday 24 October 2023.
Myke was unfortunately unable to join today’s meeting due to illness.
The pull request for moving clefs into their own key in the measure object (#312) has been merged, but in the process of working on this it became clear that we needed to reconsider how we encode the position of clefs within the bar (#313). We spent the bulk of the meeting discussing different possible approaches, and the two leading contenders are to add an extra dimension to the way the position is defined in order to fully qualify it relative to grace notes, either using a rhythmic offset or using an index into the list of grace notes at that position. Adrian will write up these two approaches and their pros and cons as we understand them in the issue, and we look forward to further community feedback.
Adrian plans to update the MNX converter to convert clefs following the completion of the initial work on moving clefs.
The next co-chairs’ meeting is scheduled for Tuesday 12 October.
Adrian has updated the MNX converter to output the new JSON format (GitHub commit). There are a few remaining details that need to be resolved (clefs, repeat endings, and tuplets) but these will be taken care of in due course. It’s not yet ready for prime time, so community members should hold off on testing the converter for the time being.
In the course of working on this, it emerged that the current design for the encoding of clefs is a little awkward. Clefs are currently encoded in the part measure object inside the content key, intermingled with sequences (that hold notes and rests). After some discussion, we agreed that it made sense to simplify part measure by moving clefs into a top-level key at the same level as beams, allowing us to remove the content key and have beams, clefs, and sequences at the same level within part measure.
Next up, Adrian will focus on implementing more of the MNX specification in the MNX converter, as this will likely flush out a few more awkward design issues like the clefs issue we discussed today.
Adrian also plans to look at the pull request (#308) contributed by Paul Overell to provide a JSON schema for MNX, and will figure out the next steps for how to integrate this schema into the project.
The next co-chairs’ meeting will be on Tuesday 28 September 2023.
We had some excellent bug reports on the MNX example documents from community member Paul Overell in issue #306, and Adrian has worked through them to fix them all. Thanks to Paul for this very detailed look at the examples.
Adrian has also completed the work discussed at our last meeting for accidentals in issue #288 and both the specification and examples have been updated.
We briefly discussed a couple of the remaining issues that have arisen from the transition from XML to JSON. We decided to close issue #298 concerning start and end repeat barlines, and issue #296 concerning the encoding of global measures, with no further action.
Next up, Adrian is going to update the MNX converter project to output JSON. The test suite for the MNX converter also needs to be updated to reflect the recent changes to remove micro syntaxes, but we think it’s reasonably certain that the subset of the syntax in these tests is now more or less set in stone. So once this is updated to output JSON, this should provide a stable foundation for future development.
Myke has decided that issue #492 concerning the way MusicXML encodes different short/tick barlines should be handled in MusicXML. In due course we will decide how the differences should be encoded: possibilities include extending the bar-style enumeration with new values, or specifying how the vertical extent of the barline should be specified relative to the staff lines on a five-line staff.
The next co-chairs’ meeting will be in two weeks on Thursday 14 September.
Adrian has committed the changes for note value quantity for tuplets to be a structured object instead of using the duration microsyntax, and the changes for note pitch to use a structured object containing the step, octave and optional alter value instead of using the pitch microsyntax. The lion’s share of the work was updating all of the examples, since all of the examples contain many pitches.
With these changes, we have completed the project to eliminate the remaining microsyntaxes in MNX (discussion #293). While we were verifying this, we decided that we can now eliminate the page about parsing microsyntaxes, and noticed also that the Styling an MNX document page still uses the old XML-based format, so Adrian will take care of these next.
For the remainder of the meeting, we discussed issue #288, concerning the former accidental element of the note object. Following broadly in the footsteps of Myke’s proposal, we have settled on a new accidentalDisplay object in the note object which will have three boolean key/value pairs, show, editorial and cautionary. Adrian will work on the specification and examples for this ahead of the next meeting.
The next meeting is scheduled for Thursday 31 August 2023.
Having proposed it some six months ago, there has been no dissention to the idea of deprecating score-timewise, so the co-chairs have decided to officially deprecate this time model in MusicXML 4.1 and plan to remove it altogether in the next release following.
Adrian has updated the documentation and examples to replace the microsyntax for note duration as discussed at the last co-chairs’ meeting.
Following on from the last meeting, we discussed the note value quantity type, which is currently used to describe the time relationship in tuplets. We have decided to retain the name “note value quantity” and change the object such that it will contain a duration object (as specified in the last meeting) along with a multiple value. This will have the advantage of making the relationship between the inner and outer values in the tuplet clearer, and will also provide us with a generic object that we can use elsewhere.
We also discussed the microsyntax currently specified for pitch, and decided on its replacement. We will describe pitch using three values: step, which will specify the note name; octave, which will specify the octave number, where the octave containing middle C will be numbered 4 (in line with Scientific Pitch Notation); and alter, which will specify the number of half-steps (semitones) by which the written pitch is raised or lowered, either by an explicit accidental or by the key signature. alter will simply use an integer in the range -3 (for a note lowered by three half-steps, e.g. a triple flat) to 3 (for a note raised by three half-steps, e.g. a triple sharp). We have explicitly decided not to handle microtonal pitches or indeed any specifics about how information about the appearance of accidentals should be encoded at this stage, but will return to this in future as needed.
Adrian will work on updating the documentation in line with this new decision ahead of our next meeting.
The next co-chairs’ meeting will be on Thursday 17 August 2023.
Adrian has updated the specification and examples for time signatures following the recent discussions about how to replace the originally specified microsyntax.
The main topic of discussion in today’s meeting was the replacement of the note value microsyntax. After considering a number of different factors, we decided on the creation of a new duration key for the event object that will itself hold a new object with two key-value pairs: base will use a string-based enumeration, heavily based on the equivalent note-type value in MusicXML, to specify the notehead duration; and dots will use an integer to represent the number of rhythm/augmentation dots on the note. dots can be omitted if the value is 0.
Following the conclusion reached in today’s meeting, Adrian will update the MNX specification and example documents to include these changes.
The next meeting will be in two weeks, on Thursday 3 August 2023.