Evan Lenz

I discovered and joined the Google group for the MNMA. Now I’m reading lots of interesting discussions about alternative notations, 7-5 keyboards (traditional piano keyboard: 7 white, 5 black) vs. 6-6 keyboards (like Janko and Chromatone). One thing I really like about the general feel of these discussions is the openness with which people greet each other’s ideas. Rather than clamoring to promote their pet notation systems at the expense of others, they generally seem to embrace new ideas as contributing to progress. They seem to embody their declared purpose well:

The MNMA is an international nonprofit organization dedicated to exploring ways to make reading and playing music easier to learn and enjoy. This is our forum for open discussion of music notation improvement, alternative music notations, and related topics.

One thing I think is missing in the discussions is an explicit emphasis on use cases. Klavarskribo and some of the other ANs (which in the MNMA forum is shorthand for “alternative notation”) as well as TN (“traditional notation”) are each what I would call a general-purpose music notation system: a single system designed to support pretty much any piece of Western music, and any activity relating to that piece of music. But I wouldn’t assume that the same notation would be equally well-suited to the very different activities of sight-reading, learning a piece for the first time, and analyzing a piece, to name a few. Similarly, I wouldn’t assume that a given notation would serve equally well for all pieces of music. In one of the MNMA forum discussions, someone mentioned that:

One person on the LilyPond list wanted to see Bartók in a chromatic
staff in order to see the symmetry. With just accidentals, and no
vertical change of position, the symmetry is hidden, just as TN hides
the symmetry.

Each piece has a logic of its own. A one-size-fits-all approach to notation is guaranteed to obscure much of that logic. The extent to which the composer’s structural intentions are clearly revealed will be haphazard if the notation is designed or chosen independently of the piece being represented.

So along with “use cases” and “refactoring”, I’d like to borrow another term from software engineering: “domain-specific languages”. But let’s modify that slightly: PSLs (piece-specific languages). And PSLs would have a leg up on DSLs, because we wouldn’t necessarily have to make them dumb enough for a computer to understand.