It is hoped that developers of new XML-encodings in different domains can use Chronicle as a powerful base layer. The software can also be useful for researchers who need an easy and flexible way to store XML-data.
TopIntroduction
The design of an encoding format for music is far from trivial. Apart from the actual symbolic content (such as notes, lyrics, chords, etc.), the designer has to solve typical problems that have to do with time, structure, groups, repetition. Wiggins (2009) and Steyn (2002) propose a number of essential features that a qualitative encoding should exhibit, such as readability, conciseness, expressive power, openness to extension and so on. However, so far, few or no encoding formats are available that can stand these criteria.
The present chapter introduces a new approach to the encoding of symbolic music and other complex time structures, by means of the Chronicle system. The core idea behind the Chronicle system is based on the notion of “an event,” which is a thing that happens at a certain moment in time, refers to a certain amount of data, and is structured in relation to other events. The supported types of event data can be freely chosen. For instance, one can decide to use events for the encoding of note onsets, note offsets, bar lines, chords, clefs, key signatures, slur starts, slur stops, section names, metadata like song-title or composer, and so on. The Chronicle system offers powerful and versatile support for grouping events and for dealing with timescales and timescale mappings, and a unique mechanism for non-intrusive association of information. The Chronicle system offers solutions to some important issues related to the representation of time and structure, without having to specify content-specific aspects of what is represented.
The Chronicle system consists of several components. The most “visible” part is an XML-based file format or, to be more precise, a set of four XML-schemas, each one representing a different “level.” Next to this external representation, Chronicle will also provide internal representations in the form of object models in a number of programming languages. The third component comprises software libraries and tools for the manipulation of Chronicle data, for reading and writing XML, for converting between levels, etc. The idea behind Chronicle is thus based on a general representational format for events that occur in time. Given the fact that music can be conceived as events over time, it is straightforward to apply the Chronicle system to the musical domain.
It is our hope that format developers may use Chronicle as the skeleton for new encodings. Instead of starting from scratch, they can benefit from the general organizational mechanisms and software support provided, allowing them to concentrate on domain-specific issues. It should be noted that Chronicle can be used not only for different types of music (non-western, contemporary, ancient, pop, …) but for all kinds of systems involving time and structure like poetry, dance, planning and scheduling, etc. Although the primary focus is on symbolic music, Chronicle is also appropriate for tagging and labeling events in audio or multimedia, musical gestures recorded by motion capture systems, or to represent intermediate data that is used e.g. in music algorithms (e.g. chroma-vectors in information retrieval, key-fields in pitch spelling, etc.).
The present chapter gives an introduction to the Chronicle system. The first part situates the Chronicle system in a multitude of already existing encoding schemes for music. The second part gives an introduction to the Chronicle system. The third part contains the discussion and the conclusion.