An Object-Oriented Music Model

In chapter 2, and more precisely in sections 2.4 and 2.6, we reviewed different music frameworks and languages. Each of them presented, more or less explicitly, a model of the music domain.

In this chapter we will present an object-oriented music model. Departing from the basic DSPOOM metamodel presented in chapter 4 we will create a particular instance of the metamodel for representing musical information. It is important to note, though, that the scope of our music model is much narrower. We are not trying to build a general metamodel useful in all situations but rather a particular model to prove the usefulness of object-orientation in general and the DSPOOM metamodel in particular in the music domain. Nevertheless, it is important to note that this model shares many features with others presented in chapter 2, particularly the one implemented in the NeXT Music Kit (see section 2.4).

Just as in the previous chapter we stated that any entity in an audio system is a sound object, we will now consider that any entity in a music system is a music object. A music object cannot sound or be heard unless it is somehow converted into a sound object. In order to generate a particular sound object usually several musical objects have to interact and finally undergo a synthesis process. In that sense our idea of music/sound object is somehow similar to that of Kyma's, presented in section 2.5.

The music domain is made of many different classes whose objects finally influence the performance. Nevertheless, and as a first approach, our music model distinguishes the following classes: Instrument, Generator, Note and Score.

It is important to note that our music model is object-oriented and not ``event-oriented''. By event-oriented we are referring to models such as Siren/MODE (see section 2.4) where, although objects are used, the key and central modeling concept is the event. Usually, music event-oriented models center the whole model around the concept of Note, and a Note is modeled as a particular kind of event. An event is in that case defined as an object that has a duration and possibly other properties (see [Pope, 1998b] or [Pope, 1991c], for example).

In our object-oriented metamodel the word ``event'' is understood in the systems engineering sense. According to Law and Kelton ``An event is an instantaneous occurrence that may change the state of the system'' [Law and Kelton, 2000]. Events are directly related to object-oriented messages and messages are sent to objects in order to modify their state. Events have no duration, as far as we are concerned they are instantaneous occurrences. For that reason, it is clear that in our model Notes are objects and not events. An event may be the message sent to a Note in order to change its tuning or to make it stop. Nevertheless, and using a loose variation of the Command pattern (see [Gamma et al., 1995]) we can interpret a message, event or command as an object. We will further develop the model in the next sections.