XML Framework for Score Data

This page explains the object framework which my current composing environment uses to represent musical scores. Among other features, this framework separates shared ensembles from specific score details. Another feature of my framework is the use of contours to control indications such as tempo, velocity, pedalling, and so forth. Also significant are the use of ratios to represent time and duration, along with the use of letter names and accidentals to represent pitch.

Readers interested in the application programming interface for my ensemble/score objects may consult the Java documentation paying closest attention to classes net.charlesames.music.ensemble.entity.Ensemble and net.charlesames.music.score.Score. The present page explains the framework from the perspective of its two XML file formats, enriched with the odd comment about implementation. However, there is basically a one-to-one correspondence between XML elements and framework objects. The XML schema files ensemble.xsd and score.xsd include “implementing class” annotations documenting how XML entities in files relate to programming objects in memory.


Ever since Franco of Cologne, musical notation has assumed that music is organized around an underlying beat. That is, there is a particular neume to which all durations are related by simple mathematical ratios. There were just two duration symbols in Franco's day, the long and the breve, and it took either two or three breves to make a long. The next century witnessed the appearance of increasingly fine-grained durations — semibreve, minim, crochet, and quaver — and of time signatures, dots, ties. The appearance of explicitly bracketed tuplets is difficult for this non-historian to date; composers such as Philippe de Vitry were very casual about how many minims made up a semibreve. However a very powerful system of rhythmic notation was clearly well established by the end of the Medieval era, and this system had several benefits:


In late 2009 I found myself with time of my hands, and so determined to resume the computer music activities I had drifted away from during the 1990's. Of that earlier effort I had nothing left but memories and an attic full of now-obsolete hardware that Ray Kurzweil had given me. It was time to start anew, and most basic thing I needed was a generic way of representing musical scores. This representation needed to satisfy several requirements:

Being myself, I never seriously considered adopting an existing framework. This was something I wanted personal control over. Yet I didn't entirely go my own way. I did adopt XML for native data input and output. Although verbose, XML offered a familiar, readable format which directly mirrors the objects being saved and loaded. As things turned out my own XML solution for score data shares very little in common with MusicXML. In fact all that my own XML format does share with MusicXML are features which my MusicXML file-export routine simply passes along into the exported file.

In the end I opted to separate my score framework into two components, the ensemble component which can be shared between multiple scores, and the score component, which holds the performance details of a specific piece or movement. Separating the ensemble from other score details means that score properties that multiple scores may hold in common — as for example when the scores are themselves movements of a larger composition — can be stored in a single memory structure and persisted in one common file. Each score instance can then reference this mutual ensemble, either using a pointer in memory or a file path on disk.

The ensemble and its hierarchy of supporting objects define the vertical structure of a musical composition. By ‘vertical’ I mean the voices, the contours that control voice attributes such as dynamics, the instruments that the voices use to produces timbres, and the choirs that indicate how voices, or sets of voices, ally with one another. So for instance voices in the same choir might take dynamics from the same contour.

The idea of abstracting the ensemble away from other score attributes was first described by my 1985 article on “The ASHTON Score-Transcription Utility”. The present implementation abstracts things further by separating how the score is described in memory from the Ashton score-building engine, and by separating the score-building engine from the parser which interprets Alan Ashton's linear music code. Thus the conversion routines which translate ensemble/score objects into MUSIC-N note lists, MIDI files, or MusicXML become generally accessible to the new composing programs I was developing.

Next topic: Ensemble Data

© Charles Ames Page created: 2013-10-16 Last updated: 2017-03-12