Announcing notationref (music notation taxonomy for developers)

[adrianholovaty]

I've started a new project, a taxonomy of music notation concepts called notationref:

https://w3c-cg.github.io/music-notationref/

This began many months ago as an attempt to form a to-do list for notational concepts to include in MNX. But I quickly realized it would be a useful resource in its own right, for developers of music notation software in general. For example, I've started using it internally at Soundslice to keep track of which notations are supported by the various aspects of our product.

For more information, please see the readme here:

https://github.com/w3c-cg/music-notationref

Of interest to MNX development is: I've documented the current state of MNX for each of the 800+ notational concepts, and I took a stab at cataloging which of them should be included in version 1.0. These are marked with the text "planned for 1.0." So we finally have a proper to-do list!

As mentioned in the readme, this is far from complete (and it's probably impossible to make a full taxonomy of music notation concepts). But perfect is the enemy of the good, and I expect to continue fleshing it out with help from the community. Starting this from scratch was quite daunting, but it's much easier to add to it now that a baseline has been established. So please consider this an invitation to make contributions to the notationref project, adding notational concepts that aren't included yet.

[rpatters1]

This is a great start. I have some issues that I am adding here just because they are touched here. We have discussed them elsewhere.

Layout changes

I have yet to be convinced that the current layout change implementation is not a terrible mistake. In general, all the requirements that appear to be headed for layout changes will lead to geometric explosions of layouts and be tedious and complex for legacy apps to import (or even export) reliably.

I think the thing I hate the most about layout changes as currently defined is the need to re-specify a complete new layout just to change the staff attributes of a single staff. It is so wasteful. The geometric explosion comes when multiple parts are each changing at different times on the same system. I wonder if we don't need a per-staff layout change concept that does not require creating a new layout for the entire measure stack.

Having said that, both Finale and MuseScore change staff attributes at musical locations on semantic staff entities. For example, changes in instrument, in stem directions, number of staff lines, element visibility, etc. are tied to musical locations. MNX appears to tie them to layouts. Given the arbitrary nature of layouts, it seems like useful interchange of these features will not be reliably possible. Even just to export them will require tying the export to a specific page layout.

Related: The lack of staff as a semantic entity

The MNX committee seems determined that there will never be a semantic entity for staff (independent of layouts), and this is a surprising choice. Much of the complexity introduced by layout changes flows from the lack of a staff entity. The free-wheeling layouts envisioned as a result are not compatible with much of the legacy software world. Somehow it has to be tamed, at least optionally. (Similar to tie target types.)

Ideas to tame layouts:

• an optional score id (or layout Id, but I think score id) for the full score (in global)
• an optional score id for each part (in part).

Instrument barlines

This is an undefined concept that does not exist in the MNX spec, except as a magic hand wave in the staff group barline style choices. If we want to have an instrument barline, it must be defined in the data for the instrument. But this gets into defining a staff group for the instrument that is not part of a layout. Do we want to go there?

Personally, I think we should discard the concept. Layouts determine braces and barline connectivity. Instruments/parts should not. I would consider the concept of an optional layout Id for the part that can be used as the default if not overridden by another layout. But that idea would not require instrument barlines, and I'm not sure how useful it would actually be. As optional scoreid for a part (mentioned above) seems like all we'd need.

Transposition as notation separate from instrument transposition

Right now MNX conflates parts and instruments. So perhaps it makes sense to carry a transposition with the instrument. They are, after all, built acoustically in keys. But this idea is not particularly useful for notation. Transposition as notation is separate from the acoustic properties of the instrument. We do not (usually) write for Bb Trombone with Bb transposition. Conversely, F horn and C trumpet read notation in many different transpositions that frequently change throughout the course of a piece. This is standard practice and must be representable in MNX. Currently it is not.

Personally, I think instrument transposition is not a useful concept for notation and should be discarded. Transposition should be moved to the part measure and work similarly to clefs. In fact, transposition serves much of the same notational purpose as clefs, and many people learn to read scores by treating transposition as clefs. (F horn is mezzo-soprano clef: fun stuff.)

[rpatters1]

I am very happy with the scope of MNX 1.0 as documented here, with one exception. I am astonished that word extensions on lyrics are not included in 1.0. It is a fundamental notation, and the implementation seems like it should be relatively simple.

Also, if the committee is serious about adding all of that by the end of the year, the cadence of decisions needs to increase considerably. 😅