A programmer's environment for music analysis

Abstract

ion, that is complexity hiding, is one of the driving forces in arriving at a design of a programming environment for a musicologist. As far as possible, the underlying complexity of representation should not be a concern of the user. Here, complexity results from the nature of the notation itself and from the underlying computer representation. As far as is possible, the complexity arising from both of these sources should be hidden from the user. It should not matter to the user, for example, whether the score representation uses pointers with dynamically created linked lists, arrays or some other construct. The user view should depend on close analogies with a musicologist's view of the paper score, rather than with the computer representation of the score. One useful metaphor is found in some of the underlying structures of objectoriented programming and design. Objected-orientation(OO) conceives of autonomous objects that are encapsulations of data and procedures. The internal details of objects are hidden from the outside world, in this case the musicologist-programmer. Communication with these objects is by means of the mechanism of message passing, or invoking member function, to use the C++ terminology. The principles involved here are illustrated by an example. Suppose that we have a score of the second movement of Tschaikovsky's fifth symphony is represented by an object, let us call it TschaikovskySymphony5-2. In an OO environment, the object is created in the computer in a form that contains all the essential score information that might be conceivably used by an analyst. This information may be accessed by sending the object a message. We could send messages to it such as 2: Corpus-based Musicology. 26 What is the starting time signature? What is the starting key signature? etc. The object TschaikovskySymphony5-2 will have enough built-in functionality to be able to answer questions such as these. ---getTimeSig ---> TschaikovskySymphony5.2 ----> (12,8) (message to object) (object) (response message) In a C++ program this will appear as the following line of code TschaikovskySymphony5-2.getTimeSig() Using a programming environment that supports encapsulation and message passing has a number of benefits over the use of non-objected-oriented environments. Encapsulation ensures that it is difficult for the user to corrupt accidentally the internal representation of the score. An arbitrary level of complexity may be hidden by the combination of message passing and encapsulation. For example, the above message, getTimeSig() could be implemented as a search for the first time signature on the first stave of the score, an action that would involve traversing through the initial information of the score, past the clef and the key signature and continuing until the time signature is reached. This complexity, and the complexity of how the score is represented in the first place, is hidden from the user. All the user needs to know is what valid messages or member functions to use and of course, to know the format of replies and to be able to interpret what they mean. Here the replies depend for their form on the allowable constructs within the programming language and on the way in which they are interpreted. It will not be clear at this stage how we might use the message-passing metaphor to access the basic music information internal to the score, such as is found in notes and rests. This will form the main preoccupation of chapter 5. 2.4.2.2 Multiple Representations. Internal representation of score is basically two-dimensional; file representations are one dimensional. File representations may be based on alphanumeric code. Alphanumeric representation codes include those already discussed such as ALMA, and 2: Corpus-based Musicology. 27 DARMS. An advantage of such alphanumeric codes is that they can be created directly with a text editor and they can be inspected, although these aspects are becoming less important with the development of GUI and MIDI interfaces. Non-alphabetic file representations are possible using 'flattened' versions of internal representations. File versions that are close to the internal version could optimise input/output time efficiency. A range of possibilities is illustrated in Fig 2.2. 2: Corpus-based Musicology. Input Main Store Output Further Processing