Co-chairs’ MNX workshop – July 4, 2025

On Friday 4 July 2025, the three co-chairs were able to meet in London and spent the whole day working together in person on the MNX specification.

Instrument transposition

We started the day discussing issue #287, concerning the handling of instrument transpositions and their effect on key signatures and note pitches when rendering scores in transposed pitch. Instrument transposition is defined at the level of the part object using a new interval type that defines the number of diatonic and chromatic steps required. We did give due consideration to the proposal to define transpositions in terms of the number of fifths and octaves, but ultimately decided that it did not give us significant advantages, though we are leaving our options open for enhancing the interval type to handle other ways of defining intervals in future.

For key signatures, we decided to define a new keyFifthsFlipAt value, also specified in the part’s instrument transposition, that specifies the number of fifths in the key object (i.e. defining how many flats or sharps appear) before the key signature should be “flipped”, i.e. from sharps to flats (by subtracting 12 fifths) or from flats to sharps (by adding 12 fifths).

For notes themselves, we have defined a new written object, which for now contains a single new value, diatonicDelta, expressing the number of diatonic steps that should be added or subtracted from the calculated pitch after considering the part transposition and any required enharmonic flip of the key signature to determine the final written pitch.

Adrian will provide some new example documents that show these new aspects of the specification in action soon. The basic changes to the specification are already live.

Single-line staves

As a precursor to discussing how to encode untuned percussion, we first turned our attention to how single-line staves should be encoded. We agreed to replace the current staves object in part with a new object that describes the number and position of the staff lines in a staff. Remember that we use a staff position type to describe the positions of things like clefs: 0 corresponds to the middle line of a five-line staff, 2 to the line above, 4 to the top line, -2 to the line below the middle line, and -4 to the bottom line. So staves will now be an array of stave objects. A stave object will by default represent a five-line staff (i.e. five staff lines, with positions -4, -2, 0, 2, 4). To encode a single-line staff, you would create a stave object with a single staff line, normally with position 0.

The changes to the specification for these changes will be made soon.

Percussion

To encode unpitched or untuned percussion, we settled upon adding a new parallel object to event that can be used instead of note. kitNote will represent a note on a percussion kit. A percussion kit may be either a standard drum set or another collection of percussion instruments, for example a set of orchestral percussion instruments. The kit definition itself will live in the part, and will specify the instruments in the kit in terms of their staff position on a five-line staff, notehead, and markings (articulations, etc.). kitNote specifies the kitComponent used for that note, which determines the staff position, notehead, markings, etc. by looking up the component in the kit.

The initial changes for unpitched percussion have already been committed to the spec, with more details and examples to follow soon.

Multi-note tremolos

We decided that multi-note tremolos should be encoded in a similar fashion to tuplets. Tuplets are encoded in sequences as a nested content object, allowing events to be encoded with inner and outer ratios specifying the relationship between the notated and effective durations. Multi-note tremolos are normally notated using durations twice as long as their effective duration, representing an inner ratio of 2:1, so we will encode tremolos using their written durations in their own nested content object. Adrian will write up the changes for the specification in due course.

Rich text

At the end of the day, we briefly discussed a proposal for the encoding of rich text. We propose a formattedText object, which contains an array of objects that can either represent regular text or music symbols. Each chunk that requires different formatting will be encoded in its own object, and each object is appended one after the other without any additional whitespace (so whitespace at changes of formatting will need to be encoded in each chunk of text). For regular text, the optional style object will allow us to specify font family, style, size, and other similar properties. For music text, the content will be represented by an array of SMuFL glyph names. It will be possible to encode line breaks using \n in the content strings.

Some more details remain to be worked out, but we will produce a formal proposal for this scheme in due course.

Next meeting

After a very productive day working together, our next meeting will be in two weeks, on Thursday 17 July 2025.