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 a pull request (#322) to address issue #103 with a proposal for the encoding of 11 different markings, including all the MusicXML articulations (with the exception of the markings that should be note-specific, namely the jazz articulations like scoop and fall) and single-note tremolos. We decided to go ahead and merge this pull request since there has been no dissent from the community on the proposal as described in the original issue.
As a next step, Adrian will implement support for these new markings in the MNX converter.
We also briefly discussed Myke’s issue #323 about the reuse of the word position to refer to both rhythmic position and vertical position within the staff, and we propose using staffPosition for position with the staff, to disambiguate the two dimensions.
The next co-chairs’ meeting is scheduled for Thursday 7 March 2024.
Adrian has been continuing to think about how to encode articulations (issue #103). In order to side-step the issue of determining once and for all what constitutes an articulation, which could be a controversial issue, he is proposing that we use a less semantic, more general way of grouping notations that apply to all the notes in a chord, i.e. in MNX terms at the event level.
After some further discussion, we have settled on the idea of having an object called markings within event that defines a set of markings that can be added to the event; for example, staccato, tenuto, accent, marcato, and so on. These will be objects in their own right, but can typically be empty unless they need to define any specific additional information such as placement, symbol overrides, etc.
Having arrived at a consensus among the co-chairs, Adrian will now prepare a pull request with a proposal for community feedback.
The next co-chairs’ meeting will be on Tuesday 22 February 2024.
Adrian has prepared a proposal for the encoding of articulations (issue #103). We discussed the pros and cons of storing articulations directly within the event or within a dictionary or list, and this became a wide-ranging discussion about how similar sorts of note- or event-specific notations – including ornaments, instrument-specific techniques, etc. – could be encoded. There is certainly a lot of detail for us and the community to get our teeth into.
The concrete outcome of this discussion was that we agreed it would make sense to encode the articulations within a structure (either a list or dictionary) in the event, rather than encoding each one in the top level of the event, because it seems clear that there will be many more items that need to be encoded at this level, and we want to avoid having too many top-level keys at the event level.
Community feedback on the proposal for articulations is welcomed.
The next co-chairs meeting will take place on Thursday 8 February.
Adrian has merged pull request #319 regarding the automatic JSON schema. Myke suggested changing the indentation to two spaces, which Adrian has also done. Adrian is working on a further refinement to include the allowed enumeration values for data types in the JSON schema (issue #321), but this requires some additional work on the doc generator tool, so this is ongoing.
We have closed issue #308 from Paul Overell for the creation of the JSON schema, with grateful thanks to Paul for all his work on this issue.
Adrian has also made a pass through the JSON key names and has made the use of the term “staff” consistent; previously we had a mixture of “stave” and “staff”. We will standardise on “staff” singular and “staves” plural, as this matches common usage.
We also briefly discussed implementing articulations (issue #103), and Adrian will work on a proposal that uses the same basic types as MusicXML for community review as soon as possible.
The next co-chairs’ meeting is scheduled for Thursday 25 January.
Adrian was planning to merge the pull request for the automatic generation of the JSON schema (pull request #319), but Paul Overell suggested a further enhancement for enriching the data types for integers and enumerations, which Adrian is in the process of implementing.
We discussed whether it would be a good idea to merge what has already been done and then follow up with a smaller change set for the delta, and Adrian agreed that he would do this.
Next co-chairs’ meeting
The next co-chairs’ meeting will be on Thursday 11 January 2024. The co-chairs wish everybody in the community group a happy and restful holiday period and look forward to further valuable collaboration on the development of our projects next year.
Adrian has also modified the docs generator system to create a JSON schema automatically (pull request #319) from the specification. Adrian is grateful to Paul Overell (@paul-bayleaf) for the work he has done on manually creating and updating a JSON schema file to MNX up to this point – his work has made it much quicker to check that the resulting automatically generated JSON schema is complete and correct. So many thanks to Paul!
Adrian would welcome feedback from community members (especially Paul) on the correctness and completeness of the JSON schema. He plans to merge these changes within a week or so, unless there are any problems found in community testing.
Adrian has also added support for grace notes to the MNX converter, along with a new test in its test suite.
Adrian proposes as the next order of business that he address a number of small and uncontroversial changes in service of making it possible to generate MNX files using the MNX converter that are more complete for so-called “simple” music – though exactly what constitutes simple music is of course up for grabs.
The final co-chairs’ meeting of the year will be in the week of 18 December, date to be confirmed.
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.