Music notation is a rich source of representational problems. One of the major problems is that music notation is not just a mechanical transformation of performance information. Performance nuance is lost in going from performance to notation, and symbolic structure is lost in the translation from notation to performance. There is evidence of strong relationships between structure and performance nuance (Palmer 1989; Clark 1991), but it seems unlikely that the relationships are strong enough to guarantee lossless transformations.
It seems that music notation rules are made to be broken. Donald Byrd's thesis contains an excellent discussion of notational variations and the impossibility of automatic music notation layout (Byrd 1984). Especially interesting is the fact that his examples, numbering about 100, all come from established, traditional composers and publishers. Two examples are the Henle edition of Chopin's Nocturne, op. 15, no. 2, in which one note head serves both as a regular and a triplet sixteenth, and the Peters/Sauer edition of Brahm's Capriccio, op. 76, no. 1, in which a written dotted half note has an actual duration of 11 sixteenths!
Another issue is that notation is visual and leaves open many layout choices. Thus, notation is partly a graphics design task, and manual layout is necessary. Representations for music notation usually include the representation of musical structure, such as key and time signatures, bar lines, beams, slurs, etc., and also graphical information such as staff position, stem direction, and graphical positioning. In many cases, layout information is implied by musical structure, but manual overrides are sometimes necessary.
The need to represent visual layout information, some of which cannot be generated automatically, has important implications for music notation systems. One is that copying parts from a score cannot be a fully automatic process, a problem that commercial notation systems have largely ignored. Most music notation programs allow the user to convert a score file into a set of parts files. However, complex scores will inevitably have many details that must be manually specified for each part, including page breaks, cues, and other notation that would not appear in the score. A problem occurs if changes are made to the score after parts have been manually corrected. Either the changes must be manually transferred to each part, or alternatively, the parts can be regenerated automatically. In the first case, there is no support for consistency between the score and the parts; in the second case, the manual adjustments to each part are lost and must be redone by hand.
A solution to this problem with parts is to represent parts as views on the score (Dannenberg 1986) A view of a data structure contains a subset of the information in the data structure and sometimes provides alternative or additional data to what is in the data structure. The idea is to keep shared data in one place so that a change in the score will automatically be propagated to the parts, and part-specific layout information can be maintained for each part (view).
Views have many other potential applications. Alternative notations for a single piece of music can be represented as views (Buxton et al. 1979). Even repeated sections of music might be represented as views. For example, it is common notational practice to indicate that a section of music is to be repeated.
Often, each repetition has its own ending, or notation such as "tacet the first time." This is essentially a view mechanism in operation; each repetition shares most of the underlying information, but there are a few local alterations. If repeats are to be notated once but performed twice, views offer a mechanism for representing performance variations between the first and second repeat.
Carrying this to an extreme, we can imagine views as a general mechanism to represent structure in music. Imagine a representation in which motives are represented only once, and each occurrence is some kind of view, perhaps with local alterations and transformations, of the motive. Such a scheme would quickly lead to many interesting problems. If a note in a view is edited, and then the original note in the motive is deleted, should the view's note be deleted as well? Can the user control such decisions? Can views be nested? These issues have much in common with representational schemes proposed for artificial intelligence, programming languages, and databases.
One important feature of notation is that events are represented left-to-right in increasing time order, but the position is not in exact proportion to time or to beat number. An interesting situation arises when multiple tempi are present simultaneously, especially when the tempi are not related by simple fractions such as a 6/8 measure in the time of a 2/4 measure. In the more complicated situations, beat and tempo information must be combined to form absolute time, which then becomes the basis for leftto-right layout. I know of no music notation systems that can even represent this situation, much less perform reasonable layout. A similar situation would arise if absolute time notations for film, animation, or tape were to be graphically aligned with conventional music notation.
Composers would like to notate not only conventional notation but also new graphical notations. In some ways, any good computer-assisted design or graphics package could support new notation, but it would be nice to have the graphics closely tied to underlying musical structures. Graphical editing should have a corresponding effect on musical parameters, which might then control a music synthesizer. An interesting proposal along these lines was made by Daniel Oppenheim (1987), and examples of (noneditable) graphics representations have been presented by Dannenberg, Fraley, and Velikonja (l991), Brinkman (1991), Waters and Ungvary (1990), and Schottstaedt (1983)
.
Another approach to extensible notation is that of Assayag and Timis (1986), who developed an elaborate PostScript library to assist in producing complex musical graphics. The library manages constraints among connected objects so that, for example, beams can be made to terminate at the end of a particular stem and other stems can be made to touch the beam but not go beyond it. The MusScribe notation system (Hamel 1988) also abandons the issue of maintaining consistency between graphical notation and music structure by providing a graphical editor that is optimized for music notation. For example, note heads snap to staff lines and spaces, but horizontal positioning is set manually.
[ Index | Previous Paragraph | Next Paragraph ]