Computer music is an interdisciplinary field combining aspects of art, science and technology. Under the aegis of computer science as well as musicology, it has been an actively pursued research topic for some twenty years.[1]
Some of the currently active areas in computer music research include:
This thesis presents a description of the design and implementation of the Rubato system, which consists of a music input language coupled to a music performance system. Rubato is a set of tools and a programming environment that collectively allow a user to enter music into a computer using a language (called the Rubato language) that is compact, flexible and modelled closely on conventional (common practice) musical notation. Once a piece of music has been entered in this manner, it can be transformed or analysed or performed on a music synthesizer provided suitable hardware and interfacing circuits are available. Current members of the Rubato family are a compiler, an assembler and linker, an interpreter and debugger, and finally a player.
It was inevitable that the notion of programming languages specifically designed for musical applications developed not long after reseach had begun in the field of computer music. Solving musical problems and music generation with computers involves questions of efficiency, representation and modelling.[2] While it is possible for a musician or composer to encode a musical composition by embedding it within an existing general purpose programming language(1), (see Moxc : real-time programming package[3] for more details on a set of library functions that allow musical programs to be written in the C Programming language in a style similar to Moxie(2)) using a computer language which has been specifically designed for musical applications and containing the embodiment of musical paradigms will allow a wide range of compositional strategies to be realized.[2]
There is currently a widely accepted means of notating music developed by Western musical tradition which will be referred to in this thesis as Conventional Music Notation or CMN for short. This notation was devised as a visual or graphical means of encoding the interrelated properties of musical sound, including pitch, intensity, time, timbre and pace, as pictorial symbols on paper[4].
CMN encodes a static representation of musical compositions as note elements (note-heads, stems, flags and beams) together with accents, dynamics and phrase marks, upon a staff(3). It quantizes the continuous musical stream into discrete event specifications (called notes) that code parameters such as pitch, onset time and duration. If each of these parameters is regarded as a perceptual dimension in music, then notes may be regarded as points placed on the perception space encompassing the music.
CMN has been criticized for its inadequacy in representation[2]. What is denoted by CMN is but the tip of a much greater body of oral knowledge and tradition in the practices of composition, performance, and analysis. The information lost by the abstraction or quantization process is recovered through a set of implicit rules known as performance interpretation most of which are automatically assumed by trained performers realizing an encoded work.
The foremost observation that can be made about CMN is that it is designed by musicians for musicians. It combines many levels of perceptual dimensions together, resulting in a concise and effective symbolic representation. However, CMN is very difficult to represent in a formal manner due to the implicit rules of interpretation. A computer performance of a musical score omitting the interpretation rules often result in a wooden rendition of the musical piece.
Alternative means of notating music have been proposed, even as early as in the year 1742 by Jean-Jacques Rousseau[5], but it can be safely asserted that CMN continues to be the dominant means of representing music by musicians.
The above discussion would imply that using CMN as the basis of any specialized computer language for music input or performance would be difficult. Yet it is certainly possible to design and implement graphical editors that display and edit musical scores using a highly stylized subset of CMN.(4) Such editors have been implemented in the past. However, the extent of CMN embodied by these editors is often minimal, and furthermore the problems generated by the implicit rules are almost always ignored or deferred. Music performance systems that do attempt to recognize the implicit rules often employ concepts and paradigms that differ substantially from CMN. Experience has shown that the design and implementation of a substantially complete music editor or music input system incorporating most of the major features of CMN, in addition to a music performance system that recognizes performance interpretation rules, is a non-trivial exercise in artificial intelligence techniques, i.e. knowledge representation.[6]
For this reason, it is usual for compromises to be made when designing a music input language. A music input language is often regarded as an intermediary means of allowing musical information to be represented in the computer. The musical information, once represented, may then be used for musical analysis, computer music typesetting, or even music generation and performance. Music input languages may sometimes be an alphanumeric representation of a limited subset of CMN with irregularities removed and simplifications effected, but often they use substantially different representation schemes from CMN which are often idiosyncronistic in appearance and style.
The paradigms employed in the design of music input languages are often derived from the 'model' used to represent the continuous musical stream(5) and has a profound effect on the subsequent 'style' of the language. Currently, a wide variety of models are used to represent musical data, including mathematical (stochastic, combinatorial and statistic), linguistic, algorithmic, process (object oriented) and models derived from artificial intelligence.[2]
The Rubato system is a partial attempt at solving the music representation problem mentioned in the last section. It seeks not to defy the concepts and abstract principles embodied in CMN but to embrace them. Instead of finding an alternative means of representing music without the limitations imposed by CMN, it shares the same paradigms as CMN in the recognition of CMN's universal acceptance in the musical world. Hence Rubato shares with CMN some of the defects inherent to the model of representation common to both systems of music notation. However, Rubato is more formally consistent than CMN as it does not attempt to duplicate every aspect of CMN, only the concepts and axioms behind the symbolic notation rules.
The main problem of alternative representations of music is the learning curve associated with mastering the representation by the very people who would benefit the most from a music input and performance system - the electronic music synthesist, the casual composer and music analyst. Also, it is inherently difficult to transcribe music written in CMN (which comprises most of Western music!) into an alternative representation scheme. Rubato does not currently solve the problem of implicit performance interpretation rules which are missing from CMN (and hence from the Rubato language), but it is hoped that some of these rules will be encoded into the interpreter and/or player in the future so that the performance of Rubato encoded pieces will be more realistic.
The Rubato system is also an attempt at creating a music input and performance system using established techniques in compiler construction and language design and taking advantage of recent research into parallel computation and the development of concurrent languages. Rubato attempts to draw as many analogies as possible between music performance and the execution of computer software. Hence the components of the Rubato system directly parallels similar tools available in the programming environment for a computer system. Writing music into a computer is a process that can be likened to writing software that will be executed on a computing machine. For example, the music itself can be thought of as a set of algorithms for 'playing' a piece and the computer as a virtual machine designed to 'execute' these algorithms, i.e. 'play' music.
Given these analogies, the Rubato language can therefore be viewed as a computer language for expressing musical algorithms. The Rubato system can be viewed as a virtual computer system that plays music. The compiler will attempt to translate user input in a high level language into a low level language that resembles machine language on physical computers. This machine language will be further translated by the assembler into 'executable' code. Multiple music source files may also be 'linked' or merged together from portions of music compiled and assembled separately into a whole. The interpreter attempts to execute Rubato machine code by simulating a virtual music playing machine using the computer's native code and supporting hardware. If something wrong occurs, the debugger may be used to isolate problems in the music representation. Finally, at the end of the chain, the player takes the output of the interpreter and generate codes that will drive a music synthesizer connected to the computer(6). This performance will then be interpreted by human ears as the realization of the musical piece.
The Rubato system has been successively implemented on a DEC VAX 11/780 running Unix Version 8 and an IBM PC/XT running MS-DOS Version 3.30. Currently, music performance is only possible on the IBM PC/XT via a player program called adagio(1) (see The Adagio Language[3]) and the Roland MPU-401 MIDI Processing Unit.
The Rubato system is the union of the following subsystems:
This is the user interface to the system. The Rubato language is an typographic language with features similar to CMN but at the same time less inconsistent. It is highly algorithmic and employs block structuring of declarations to facilitate music analysis. The design of the Rubato language is an extension of the grand tradition of 'structured' computer languages beginning with Algol and continues on today in general purpose computer languages such as Pascal and Ada. In addition, the language feature concurrency and syncronization primitives derived from research in process concurrency that resulted in experimental languages such as Communicating Sequential Processes(CSP) and Occam.
This is again subdivided into components which taken as a whole, will accept as an input file musical pieces encoded in the Rubato language by a user and plays them on a music synthesizer. The compiler scans text files written in the Rubato language and generates intermediate assembly code suitable for processing by the assembler, which in turn will generate machine code suitable for the interpreter. The interpreter simulates the execution of the machine code. This results in a file suitable for input by the player. The player performs the music piece on an electronic synthesizer interfaced to the computer.
The following are the major modules of the Rubato system and what they do:
This compiles a source file written in the Rubato language into the assembly language suitable for the assembler. A Rubato source file is created using a text editor on the computer system and is just a normal text file. The Rubato language and compiler is portable and stable across implementations.
The Rubato assembler accepts assembly instructions in the one instruction per line format common to most assemblers for computer systems. Each assembler instruction corresponds to a musical event, such as a command to start playing a note or set a particular attribute to a certain value or a command that changes the internal state of the virtual machine. The design of the assembly language is also portable across implementations. It is in fact independent of the language. It is possible to modify the design of either the Rubato language or virtual machine without affecting the other.
The linker will link up separately compiled and assembled source files into a musical piece that can be 'executed' by the interpreter. External declarations and references can be resolved at this stage. The linker is also portable across implementations.
The interpreter will simulate the execution of the Rubato music performance machine. Essentially, it executes Rubato machine code in the host environment. Currently, the interpreter generates a text file which is then read in by a player program that actually plays the music. Hence it is portable across implementations provided each implementation uses the same format for the player file. Ideally, the interpreter should execute in 'real-time' and play the music directly onto the synthesizer hardware interface. In other words, the functionality of the interpreter and the player should be combined into one unit at the expense of portability. Besides efficiency considerations, merging the interpreter and the player will allow the language and the system to be extended in the future for human/computer interaction during the performance of the music.
The Debugger will allow machine code, whether hand-written or output generated by the compiler, to be debugged. Commands typical of a system debugger such as single-step, trace, disassembly and memory examine and state examine are available. At this stage, the debugger is quite useful for debugging both the compiler and interpreter!
Currently, the player is an independent program which is separate from the interpreter. The player used in the current implementation is called Adagio and has been developed by Roger Dannenberg[3] at Carnegie-Mellon University.
Next: Chapter 2: GENESIS AND METAMORPHOSIS
Previous: Chapter 1: PRELUDE AND OVERTURE
Back to: Table of Contents