Chapter 8: FINALE: A ROOM WITH A VIEU

In this thesis, a substantially complex and powerful music input language and performance system has been presented. The Rubato system is, however, by no means a completed design. It is still a fast evolving design. As an example, the specification of the language mentions 'envelopes', which allow continuous incremental changes to be made to an attribute over a set of notes. However, the design of envelopes have not been completed yet in both the Rubato language and the Rubato machine. Also, attributes should be able to be scaled or transposed en masse once entered into a set of notes.

The major advantages of the Rubato system over similar music input and performance systems can be gleaned by comparing the features offered by the systems discussed in the literature review against the features inherent in the language. (The performance of music in the Rubato system is as yet too simplistic for a fair comparison with other performance systems.). The following are perceived to be the strong areas of the language:

• It is easy to transcribe pieces written in CMN to Rubato. Since both systems of notation share the same model, transcriptions of musical pieces to and from both systems are relatively straightforward. As the Rubato language have concurrent capabilities, multiple lines of music can be easily coded as separate phrases which are later joined together using the chord constructor. These phrases will be performed concurrently. Hence, no serialization of the musical streams into one stream needs to be done during transcription. There is usually a direct correspondence between musical scores and Rubato programs.
• Rubato offers powerful algorithmic control on the note stream. Since the Rubato system is a virtual machine, it possesses the ability to change the flow of note generation. Constructs like iteration and selection, which are clumsy to notate in CMN, are easily specified in Rubato.
• Rubato programs are compact. Writing a Rubato program is just like writing a program in a normal high level programming language. On some scores, the Rubato representation is often more compact than the musical score. See the appendix entitled SAMPLE Rubato PROGRAMS for examples of musical scores and their transcription into Rubato programs. Most of the programs are quite small (on the order of a few Kbytes). The assembly file generated by the compiler on most of these files are in the order of tens of Kbytes. In contrast, the player files generated by even small Rubato programs can often be large, player files up to 80 KBytes in size resulting from a 5 Kbyte Rubato program are quite common. This substantiates the claim that Rubato programs are compact. The transcription of Jean-Michel Jarre's Equinoxe into the Rubato system is much more concise than the musical score on paper due to repetitions within the musical score being factored out during the transcription process.
• Rubato programs are fast and easy to code. Coding pieces in the Rubato language take time, but not nearly as much time as it would take in most other music input languages. On average, coding up a small piece of music directly into a player file takes 4 hours or more, the same piece of music only takes between half an hour to one hour to transcribe as a Rubato program. Coding pieces with a high degree of repetition, such as canons or rounds, require only a fraction of the time necessary to code the piece in most of the other music input languages discussed in the literature review.
• Rubato isolates independent sections of the music. A well transcribed music piece into Rubato is like a well written program in a high level block-structured programming language. Phrases in a section not used in any other section can be defined locally within the section. The hierarchical nature of Rubato programs parallel the hierarchical organization of musical thought.

The Rubato system currently have the following shortcomings. Most of the shortcomings are due to the system being an evolving design rather than a finished product. Few of the shortcomings are inherent in the overall design of the system and most are correctable.

• Dynamic changes in attributes such as crescendos are hard to code in the language. This problem will only be solved once envelopes are defined and implemented properly.
• The Rubato language does not as yet allow the encoding of performance directives such as phrasing.
• The representation of CMN is not as complete as it can be. Rubato's model of music is not nearly as sophisticated as CMN's model and is hopelessly inadequate at expressing new musical ideas developed in the twentieth century by the experimentalist or avant-garde school of composers.
• Rubato currently does not attempt to do sound synthesis as opposed to music synthesis. The hardware interface is just as fully capable of transmitting sound control information as note control information. However, this facility is not realised by Rubato.
• The performance system desperately needs to have performance rules encoded within it in order that it can deliver more convincing music performances.
• The implementation of the existing Rubato system can be improved.

The list of shortcomings in the Rubato system is a good pointer to future extensions that can be made to the language as well as the performance system. The system as it stands currently is an interesting experiment in how music input and performance systems can develop in the near future.

Next: Appendix 1: EBNF GRAMMAR OF THE Rubato LANGUAGE
Previous: Chapter 8: FINALE: A ROOM WITH A VIEU
Back to: Table of Contents