An XSLT library to represent the "internal state" of a MusicXML document

[infojunkie]

One of the common difficulties with processing MusicXML scores is keeping track of the implicit state of the music at any moment - e.g. at a measure, at a note event, or even at a point in time.

To give a few examples:

• Staff-level elements such as clef are carried over until they are changed
• Same for system-level (or score-level?) elements such as tempo
• On a given staff, each pitch class has a current accidental that is carried over until it is explicitly changed or reset at measure boundaries
• The cursor position (time, division) of a given note relative to its measure start or to another event.

The point of the list above is not exhaustiveness or even correctness, it just serves to illustrate the various types of musical state that implicitly exist in a score, and that invariably need to be represented in any processing software.

Recognizing the universality of this need, and to help with my own music tools, I'm maintaining an XSL library that represents and keeps track of the music state as the score is being processed. It is by no means complete, but I've been using it successfully for various applications / tools in the past few years. It can be used within other XSLT programs, but also embedded in other languages that utilize XML libraries.

Why XSL? To me, this technology represents the purest logical expression of a transformation logic. The "logistical pollution" that comes with general-purpose programming languages is kept to a minimum, which means that the logic of transformation is not obfuscated with distracting lower-level concents. Also, XSL's functional design forces the programmer to think it terms of pure functions and avoids mutable state and side-effects, which also helps with logic clarity.

But in this case, how is the music state updated as the measures are being processed? XSL includes a wonderful construct called "accumulators" which is a reactive mechanism that gets triggered upon encountering programmer-defined conditions. The simplest example is remembering the current tempo until it's changed:

<xsl:accumulator name="tempo" as="xs:double" initial-value="120">
    <xsl:accumulator-rule match="sound[@tempo]" select="@tempo"/>
</xsl:accumulator>

Here, the accumulator (state) called tempo starts out with MusicXML's default of 120, and is updated whenever the XML processor encounters a sound[@tempo] element, at which point the accumulator rule is triggered and updates the state with the value of ./@tempo. At any time, the processing application can call the XSL function accumulator-after('tempo') to retrieve that state's value.

I hope I gave you all a taste of what I'm building. If there's any interest in collaborating on this library, I'd be happy to pull it out of the current repo into its own.