Score processing and dynamic behavior

Although our focus has been on structural modeling, some principal issues con-cerning the dynamic behavior of the object model should also be discussed. This involves application of the analysis model for the performance of common tasks in computer-based notation.

Computer processing of music notation may be divided into five main tasks:

1. Data input and storage retrieval 2. Editing

3. Data storage 4. Printing 5. Playback

Each of the tasks involve some form of dynamic behavior. Data input and stor-age retrieval create new objects; e.g., by commands issued by a user or from a data input or storage representation. Editing involves making changes to an existing score, including the moving, copying, or deletion of objects. These tasks change the state of the object system. In Chapter 2.5, it was pointed out especially that editing, storage, and playback capabilities are not needed in every music notation application. At the least, however, data input causes dynamic activity in the system.

Data storage involves saving the state of an object system, for example, to a file. Printing and playback require the production of graphic and sonic represen-tations of the score, respectively. Whereas storage, printing, and playback require iteration or interpretation of the score, the state of the object system rep-resenting the score does not necessarily change. There, dynamic behavior may involve creation and manipulation of temporary objects that are not part of the music-notation object system itself, but are used to store and transmit informa-tion from the notainforma-tion objects during an iterative interpretainforma-tion process.

As an example, a music playback algorithm would iterate through each Page in a Score, each System on a Page, each Staff in a System, each CoreSymbol and Attachment on a Staff, and so on. Each Symbol encountered in the iteration pro-cess may affect the consequent CMNSymbols. The effect of each CMNSymbol would be maintained through the iteration. In an object-oriented system, an obvious solution is to use an object for data storage. We shall call the class of this hypothetical object “PlaybackEnvironment”.

According to the analysis model, CMNSymbols implement an operation named “play”. This operation would be invoked for each CMNSymbol encoun-tered during the playback process. The playback process would be started by invocation of the play operation of a Score object. The Score object would

iter-ate through its Pages and successively call their respective play operations. This process of delegating the play operation would continue down to the lowest-level objects in the aggregation hierarchy. A PlaybackEnvironment object would be passed along as a parameter of the playback operation and returned in an updated state by each invocation of “play”. The state of the PlaybackEnviron-ment would thus change according to the effect of each Symbol (such as changes in key or time signature, changes in dynamics, effects of accidentals, etc.). In a multi-staff system, a separate PlaybackEnvironment instance might be needed for each Staff. Note objects would react to play operations by producing sound events or an instruction for generating them. Most other types of Symbols would only alter the state of PlaybackEnvironment.

A similar iterative process would be needed in all the tasks listed above. In printing, the Score would invoke a “draw” operation on all of its parts, and each part would invoke the draw operation on their parts, etc. In this process another dynamic object, say, “GraphicalEnvironment”, could be used to pass on infor-mation about the position and scale of each Symbol to be drawn.

Environment objects could be also used as a way of expanding the capabili-ties of the object representation to cope with different musical styles. As pointed out by Selfridge-Field (1997c: 11-12), performance of a Western art music score requires knowledge of the conventions of the specific musical style and histori-cal era of the composition and/or notation. For example, the correct interpreta-tion of durainterpreta-tional values in Baroque music scores may differ from those conventional to a present-day reader. In the object model, specialized Playback-Environment objects could serve to represent the performance conventions of specific musical styles.

In interactive computer-based editing, a typical task is to find and select a symbol that a user clicks on with a mouse or other pointing device. If a single page of a score is visible, the search operation would be invoked on a Page object with the x and y coordinates of the pointing device as parameters for the operation. Using those coordinates, the Page object would invoke a search oper-ation for its parts, and so on, until the object pointed at is found. When an edit-ing operation is completed, adjustment of spacedit-ing may be necessary. Again, an automatic spacing algorithm would iterate, possibly in multiple passes, through each adjusted System and Staff.

In some editing tasks, the environment of symbols may also have to be taken into account. For example, if notes are moved or copied within a score, it may be necessary to preserve their pitches and durations so that they can be intelligently placed into a new environment; for example, into another key or transposed for another instrument. There are at least two ways to accomplish an “intelligent”, copy-/paste-style editing task: (1) The environment of the symbols (key

signa-ture, preceding accidentals, etc.) is carried with the copied notes; e.g., by means of a dedicated environmental object. (2) A temporary logically-oriented or hybrid representation is created by calculating the logical pitches and durations for each note. The temporary representation would be converted back into purely graphical representation when the notes are inserted into the new envi-ronment.

A simpler editing task is described below in more detail. Figure 9-3 shows a a sample UML sequence diagram (Booch et al. 1999: 245-247). It displays a hypothetical interaction process in which a user first selects a symbol then issues a command to delete it.

On the object level, interaction takes place between four objects of four classes: Page, System, Staff, and Note. It is assumed that the Page of the Score has already been selected. Therefore, a Score object is omitted from the dia-gram. The diagram shows a simplified two-step process, where one note symbol is first selected and then deleted from a staff. The diagram roughly simulates a situation in which a user selects a note on a page of a score (e.g. by clicking on the note symbol with a mouse) and then issues a “delete” command (e.g., presses the DELETE key on a keyboard).

In the diagram, the objects are shown on top. The program execution time flows from top to bottom. Communication between objects is shown with arrows. The name and arguments of the corresponding operation are attached to each arrow. An arrow drawn with a dashed line indicates the return of control to the caller of the operation. The execution time of an operation is indicated by a narrow box. Each object has a “life span” shown by a dashed vertical line. A cross symbol indicates the deletion of an object.

During the phase of symbol selection, a “selectSymbol” operation, with the coordinates of the pointing device as its parameters, is invoked on a Page object.

The Page object compares the coordinates with the positions and dimensions of the System objects that it contains. When the appropriate System is found, Page calls the selectSymbol operation of that Symbol. This process continues until the appropriate CMNSymbol, in this case a Note, is found. Control is then returned to the user. During the deletion phase, the user invokes a “deleteSelec-tion” operation of the Page object, which in turn iterates through its parts to delete all of the selected symbols that they contain.

The diagram is meant only to serve as an example of a hypothetical editing task. The exact need and behavior of algorithms depend on the application area of a particular computer program. The structure of the analysis model allows many different solutions for, say, selecting and deleting objects. Here, the use of the model and detailed forming of algorithms are regarded as design-stage issues.