Chapter 3


This chapter describes the first of the three microcomputer based composition and performance systems used to control the acoustic instruments. The system has two principal functions: translation of the original text score and performance of the translated data. These functions are somewhat enhanced with facilities for examining the various forms of the score data and the status of the system in general. It is a non-real-time system due to the computationally intensive processing needed to convert the higher level representation of the score data into the performance data. Once the score data has been translated it can be stored on disk and later loaded into the system for immediate performance. The software was written in BASIC by Chris Vaughan and a code listing appears in appendix E. The score of composition, Variations (for two instruments) (1984) is in appendix D and it is the first recording on the accompanying cassette.

3.1 The System Overview

The system under discussion here was the first to establish an efficient compositional methodology and performance interface for control over the digital piano system described in chapter 2. The nature of the performance syntax and system commands were initially responsible for an experimental approach to the production of music. This in turn, led to the discovery of some unique sounds and performance behaviour on the modified instrument in particular and to a lesser extent, the traditional piano.

The software was designed and developed concurrently with the construction of the new interface hardware and modified instrument. This allowed for quite a degree of cross development under the principal vision of extended performance. Both the interface and the piano action were evaluated with this performance criterion in mind. The modified instrument's action had to be capable of operating faster than that of the traditional piano and the new interface needed to respond to a greater data rate than the earlier communication link between the microcomputer and the piano.

The efficiency of the software in transferring data to the instruments was, however, compromised by its facility in interpreting and managing score data. The alternative of programming in assembler was considered too tedious and error prone to undertake. The BASIC programming language was used simply because it was readily available and easy to develop the application in. The fact that this BASIC is not an appropriate language for real-time activity was not a major concern at that time. In comparison with the language used (PASCAL) to develop the application discussed in chapter 2, the I/O functionality of the BASIC was clearly inefficient.

The system takes the form of a number of practical modules grouped into a composing and performance environment. The modules are accessed through a menu and their operations include:

3.2 The Formal Composing Procedure

The system distinguishes between two forms of data, both of which represent the music. The primary or initial data (ASCII text) are organised and stored by the composer in a score file. Such symbolic score data are meaningless to the instruments and require translation into the performance format. Once through the translation process the data can then be sent directly to the instruments. Unfortunately, it is extremely difficult to understand in this translated form and apart from use on those rare occasions in diagnosing system behaviour, it is seldom examined.

The score file is prepared using a standard text editor. Due to the limitations of the microcomputer system, it was not possible to integrate a text editing function with the existing translation and performance operations. The nature of the score format is described in the following sections.

3.2.1 Score Creation and Organisation

The score can be written and developed using any available text editor (an editor that puts Carriage Returns at the end of the lines) and is based around the standard text line. This format permits flexible and readily identifiable musical structures or events that can be easily distinguished from the surrounding material. The freedom to lay out the score data in just about any way was an important conceptual improvement over the earlier data organisation method (see Example 2.1). The flexibility inherent in the layout, however, is not unrestricted. Attention still has to be given to the sequence of syntactically correct operators, otherwise the result can be quite different from what is expected.

The basic sequence of operations necessary for note activation is outlined as follows, where <n> is a note between 1 - 80:

  1. Specify dynamic
  2. Select note <n> ON
  3. Wait for specific duration (may include other operations)
  4. Select note <n> OFF

An unusual aspect of the score format is having to explicitly turn notes off. It was recognised that such a small system would not adequately cope with processing either complex data structures or managing intricate timings with intermittent output operations. In the first instance, the size and complexity of the translator, given the programming language it was written in, would have substantially lengthened the processing time of the score data. Secondly, the performance of the microcomputer would have deteriorated further with managing complex timing situations. It is, in fact, doubtful whether the BASIC then available could have accessed the hardware functions necessary for the management of such timing operations.

As a consequence the score carries the burden of this task which is reflected as an increase in score complexity, and to some extent, a decrease in legibility. It could be argued that there is some benefit in displaying the location and context of note terminations especially with this type of score syntax and format. Unfortunately, the complexity of the score sometimes makes interpreting the timing of events difficult.

While there are obvious disadvantages, another with more serious side effects is that the responsibility lies with the user to ensure all notes are terminated. If a solenoid is ON for some extended time, it is likely to become less effective or even burn out.

3.2.2 Score Data Translation

At the heart of software operations is the translator which converts the higher level score data into the appropriate system and interface byte values. Running the translator results in the production of memory resident performance data which can be sent immediately to the instrument or saved on disk.

The translator functions by recognising characters or tokens (strings of characters) which form the higher level syntax. It substitutes each character or token with a value or series of values which are placed in a sequential file. This process continues until the token 'END' denoting the correct end of the score file is encountered.

If the translator encounters grammatical errors, i.e. unknown characters or incorrect syntax, it will terminate at that point. Such behaviour, while perhaps clumsy, is acceptable because the score file is at fault and must be changed. The system is not sophisticated enough to do anything about it and unfortunately the version under discussion here does not identify the location of the problem, i.e. the line in the score file. It is therefore more efficient to verify the syntax of small files, then later concatenate them into a larger file for translation.

Incorrect syntax, not detected by the translator, will result in a performance aberration which may or may not be immediately appreciable. The significance and magnitude of an error in this system is fundamentally equivalent to that likely to occur in any other performance context. The major problem is that the system can never be aware that anything is wrong and therefore cannot correct any aberrant behaviour.

3.2.3 The Score Language - Syntax and Grammar

The nature of the score representation–its symbols and sequential ordering–tends to ally it more formally with the computer science view of language rather than a musical one. This is understandable because its design origins and functional association are with computing machinery. Irrespective of a bias during development, the specification of this language requires some formal means of explaining the symbols and structure, and of defining syntactically correct scores.

A score, existing as a text file, is an ordered set of operators. A correct sequence (file) of these operators should result in a mechanically consistent interpretation of the composer's intentions. What ultimately validates these sequences as well-formed or correct is their successful interpretation by the musical instruments.

The formal notation of the symbols and the syntax of this language are expressed in Backus-Naur Form (BNF) (Gries 1971; Hopcroft and Ullman 1979; Rayward-Smith 1983; Wirth 1976). This context-independent meta-language is typically used to describe computer languages. In this case, however, it serves principally to clarify syntax and outline the grammar of the score language and is not intended as a composing strategy.

In BNF, the basic symbols of the language are called terminals. These are identifiers and numeric values. Nonterminals are sets of strings of terminals. What defines nonterminals are productions or rewrite rules. The ::= and | are meta-symbols meaning "is defined as" and "or" respectively. They associate with a symbol (nonterminal) on the left of the ::= the string of nonterminal and terminals on the right. A production may take the following form:

<nonterminal> ::= <terminals> | <nonterminals>

The most fundamental nonterminal in this language is an operator. An operator consists of a case sensitive identifier and depending on the particular identifier's function, it may or may not have an accompanying numeric value or group of values. An operator is therefore defined in BNF as follows:

<operator> ::= <identifier> | <identifier> <numeric values>

An identifier is defined as one and only one of an alphabet of special character symbols.

<identifier> ::= <character>
<character> ::= N|n|I|W|D|C|H|R|S|s|U|u|,|;
The BNF for the representation of the set of numeric values associated with some identifiers is:

<numeric value> ::= <digit sequence>
<digit sequence> ::= 0|1|2|3|4|5|6|7|8|9
|0<digit sequence>|1<digit sequence>|2<digit sequence>
|3<digit sequence>|4<digit sequence>|5<digit sequence>
|6<digit sequence>|7<digit sequence>|8<digit sequence>
|9<digit sequence>

With this notation it is possible to define higher level musical structures such as chords and melody. Depending on the complexity of the structures, it may take a considerable number of productions. Such an exercise is, however, considered more theoretical than musical and will not be pursued beyond this point. Figure 3.1 lists the operators, their function and the range of their associated numeric values. <n1> is 1 - 80, <n2> is 0 - 32767, <n3> is 0 - 31 and <n4> is 1 or 2.

N<n1> Note ON.
n<n1> Note OFF.
I<n2> Inline wait.
W<n2> End of line wait.
D<n3> Dynamic level.
C<n4> Enable interface (instrument).
H<n4> Disable interface (instrument).
R Reset the interface hardware.
S Sustain pedal ON.
s Sustain pedal OFF.
U Soft pedal ON.
u Soft pedal OFF.
, Substitute for the previous I value.
; Substitute for the current W value.

Fig. 3.1 A list of operators, their functions and associated numeric values.

U (soft pedal ON - This operator never takes a value)
N32 (note 32 ON)
N32 33 34 35 (notes 32 33 34 35 ON)

Ex. 3.1 Possible operator combinations.

It is perhaps misleading and incorrect to refer to this scoring language as high level but it does provide a framework for a logical sequence of operations. The syntax is simple yet powerful. What it lacks in sophistication is made up for in flexibility. The principal disadvantage is that complex musical structures become difficult to read and hence conceptualise. This can be somewhat overcome by score layout but numeric or even alpha-numeric data in large quantities are tedious.

No high level constructs or abstract data types are available. While they may have cut down on score space and improved legibility they tend to further burden the performance of the translator in a small system. In this specific microcomputer system, the size and complexity of the translator was balanced against the memory available for storage and the time taken to generate the performance data. Having the work reside in memory meant that no interruptions occurred from slow and random disk accesses.

3.2.4 The Duration Syntax

A tenet maintained during the development of the score language was that duration between events be as flexible and subtle as possible. A simple and conventional approach required only the acknowledgement of a duration with an associated numeric value. This form of temporal representation was employed in the context of the sequential score format.

In a score, durations between note events appear in either of two forms, designated 'W<n>' or 'I<n>', where n is in the range of 0 - 32,767. These duration operators reflect the manner in which the score must be organized into lines. The 'W' operator defines the wait values used at the end of lines in the score. Once the value, 'W<n>' has been set, it need not be explicitly declared again until the value requires changing. The translator recognises the end of line when it encounters a Carriage Return (Hex - 0D). 'I<n>', however, is used within a line and its value needs to be defined whereever the wait is required and explicitly declared with an 'I'. No durations are ever implied between events without some wait symbol. If there are consecutive repetitions of a 'I' value, their occurrence in the score can be substituted by ',', thus reducing text volume and improving the score clarity. A similar but less frequently used substitute ';' can be specified anywhere in the score resulting in a wait equivalent to the current 'Wn' value.

The use of the term, 'wait' rather than something more musically relevant, seemed necessary in the context of the linear score format. When the system encounters these duration controls it simply waits with all activities suspended.

3.2.5 Duration - Definition and Implementation

The allocation of a byte to a single operation would appear at first inefficient compared with the Pianocorder format (see Example 2.1), if it were not for the asynchronous transmission mode. This means that no data are sent unless specifically required.

If the timing of a composition is not implicit in the transmission of the data it must be embedded in the score along with the performance events. A performance score–a data file ready for immediate performance–is a mixture of timing and interface bytes (performance data). The system that outputs the data to the instrument is therefore capable of distinguishing the timing data from the performance data. Furthermore, it must act on this timing data to control the flow of outgoing events.

The note durations are controlled through the software. The output subroutine of the system which transfers data to the instruments looks for certain byte values. On recognizing a duration identifier, it reads the next byte (or bytes, until the output subroutine recognises another identifier), passes the value as a counter to a 'wait' loop which iterates for the specified number of times. The output subroutine then resumes transfer of the data to the piano until once again a delay in the transfer is required.

When the translator parses the text file for numeric values used to determine the durations between events, it stores them as either one or two (hexadecimal) values, depending the size of the initial numeric value. These values are preceded by another value which is a code that is used to interpret the following value or values. Three specific byte values were chosen as codes and are expressed here in both hexadecimal and decimal:

Hex Decimal
FD (253)
FE (254)
FF (255)

The operation of these codes is explained as follows:

FD means that the counter value for the wait loop is a byte value only and therefore in the range of 0-255. It is the simplest form of wait value and requires no processing (Figure 3.2a).

FE signifies that the next value n, was a multiple of 256. The loop will execute for 256 * n, where n is between 1-128 (Figure 3.2b).

FF defines the timing value to be greater than 256 and not a multiple of 256. FF will mean that the next byte will be a multiple of 256 and the following byte will make up the exact wait value specified. This is a combination of the previous two wait state functions (Figure 3.2c)

(a) (b) (c)

Score Data (I16 or W16) (I768 or W768) (I516 or W516)

Data (Hex) FD 10 FE 03 FF 02 04

Value = 16 = 256 * 3 = (2 * 256) + 4
= 768 = 516

Fig. 3.2 The translation of duration values from the score data format to the performance data format.

The values in Figure 3.2 are produced by the translator parsing the numeric string associated with a wait identifier ( 'I' or 'W') and providing the value is less that 32,767, the translator converts it into the appropriate byte values. This method significantly reduces the number of bytes required to represent duration in the system. If longer durations are needed then a succession of waits can be initiated.

3.2.6 Temporal Considerations

The fundamental wait unit is defined by a software delay loop and is therefore not intended to represent duration in minutes, seconds or fractions of a second. This method of timing control admits a fair degree of latitude in the performance of a work if the composer is willing to go through an intensive rehearsal period. The tempo of a work can be considered in terms of the degrees of influence exerted by each of the following classifications: clock time, basic time and tempo perturbation (Jaffe 1984). At the fundamental level there is clock time where the frequency of the wait loop provides a measured period between events. This is regular and fixed, and when the loop is in operation all activities are suspended. In the score and thus in performance, the tempo of events can be adjusted as in the traditional rubato or accelerando by adding to or taking away from the relevant clock time value. When an event or series of events is performed, i.e. output to the instruments, clock time is suspended and basic time or process time comes into effect. This classification of time and its effect on performance tempo must to a degree be compensated for by adjusting the clock time or wait loop variables.

These two classifications–clock and basic time–can be identified because of the different operations within the system. Clock time exists between event activity and basic time exists when events are active within the system. When an event or series of events are being processed clock time no longer has influence. Basic time governs temporal activity. Theoretically, the transfer of data should not make any noticeable difference but because of the I/O routines used, the overall effect is that of tempo perturbation. The length of interruption will vary depending on the amount of data transferred. In most cases it is not significant, certainly not in isolated instances. In extended passages like the first section of the author's work, Fantasie(1984), where one by one, voices are added until eight form a dense rhythmic heterophony, the effect is most noticeable. The tempo slows dramatically at the introduction of the fifth, sixth, seventh and eighth voices. The effect of tempo perturbation can be reduced by adjusting the clock time, that is, by changing duration values before and after the event. Passages either side of such a section can be altered to make any incidence of tempo perturbation less influential. To some extent it still depends on the volume of data to be transferred.

The serial format of the score unfortunately complicates the perception of individual note durations and note relationships. The numeric value of a note duration is often graphically partitioned and temporally distorted by other events, in which case, the actual duration is not clear. This is particularly true for polyphonic structures where voices and their relationships are further obscured by being interpolated within the stream. An example of this can be seen in Example 3.2.

The philosophy of composition using this system is founded upon a reasonably fast turnaround time between entering or modifying data and hearing the result. This method encourages a fluid and informal treatment of the primary score due to constant rehearsal. Here there is a contrast with the traditional static score that receives a unique interpretation (perhaps unintentionally) on each performance. As a result of the ability to constantly mold the data, subtle visual indications of tempo are often obscured by localized adjustment and subdivision. While there is a broad indication of the tempo, simply by the overall size of the numbers used, it can be deceptive without close examination.

In retrospect these few points about tempo influenced the entire approach to composing for the medium. By the time some understanding and technique had developed, any attempt to formalize a methodology was overshadowed by thoughts of a new approach and technology.

Example 3.2 illustrates the score layout, showing the sequence of the operators necessary to interpret a scale in two fundamental ways. The C major scale is first interpreted legato and then leggiero (nonlegato). Any text beginning with a '*' is treated as a comment until the next line and is omitted in the translation process. 'END' is a translator directive marking the end of the score.

* C major scale scores for legato and leggiero performance.
C1 * Enable interface for instrument 1.
D25 * Set Dynamic at about mf.
W0 * End of Line wait is set to 0
* 'I' - inline wait operator.
* ',' defaults to the previous 'I' value.
* Legato
N36 I200 N38 n36 , N40 n38 , N41 n40 , N43 n41 , N45 n43 , N47 n45 , N48 n47 , n48 W2000
* W2000 waits for that count to expire.
* Leggiero (nonlegato)
N36 I200 n36 , N38 , n38 N40 , n40 N41 , n41 N43 , n43 N45 , n45 N47 , n47 N48 , n48 W2000
R * Resets the interface, effectively clears interface activity.
H1 * The interface cannot receive any more performance data

Ex. 3.2 A C major scale scored first for legato and then leggiero performance.

3.3 The Performance Interface

Once the score data has been translated into performance data it can be played immediately by pressing the 'P' key or stored on disk as a performance file for reuse at a later time. Since the translation process takes time any significant result is worth saving immediately.

While the performance data is in memory, repeated performances can take place by pressing the 'P' key at the menu when the system is again ready for input.

3.4 New Instrumental Techniques

The nature of the score language, although relatively primitive, permitted frequent rehearsal of musical fragments. In this respect, exploration of performance characteristics could be pursued without much difficulty. As it turned out, the process was also flexible enough to allow the unexpected to occur. This amounted to the discovery of some interesting techniques and effects.

These effects are mostly confined to the modified instrument. It has the mechanical versatility to accommodate irregular and experimental behaviour which results in different ways of producing or controlling the sound. The traditional piano, on the other hand, does not have the same mechanical versatility and therefore has to be considered as functioning in an extended traditional performance capacity. Any new acoustic effect on this instrument is therefore the result of an exploitation of the peculiarities of the action not accessible through human performance.

3.4.1 The Modified Instrument

The modified instrument introduced in section 2.3.2 possesses a unique repertoire of sounds as a result of two areas of modification: the action and the damping mechanisms. The first area offered the greatest degree of control and the richest source of sounds. The skill in generating these sounds lies in the control of the solenoid/string interaction. The period in which they can produce sound is variable from a few milliseconds to several minutes (or until the solenoid fails). Consequently the string responds in a variety of ways.

An examination of the string/solenoid interaction should begin from the time of least contact, that is, when the string vibrates in response to the amount of energy delivered on impact. The hammer, in effect, has just made contact with the string but is immediately withdrawn. The sound is therefore marked by low amplitude and sparse overtones.

Amplitude and overtone complexity subsequently increase with longer contact time until an optimal duration is achieved. This optimal time is defined as the period of contact where the most efficient transfer of energy takes place. The hammer is removed at the latest time before the reflected waves begin to cause interference with the natural harmonics and partials. As the timing for ON/OFF durations is expressed in system specific values and not standard clock time, there are general timing values available.

Extending the contact time beyond the optimal period creates a disturbance in the natural evolution of the overtones. This results in a sound with an increase in artificial overtones that is audibly more complex. The hammer interferes with the reflected waves, causing changes in the pattern of the wave traveling along the string. In effect, it is similar to placing objects on the strings as in the case of a prepared piano.

The logical extension of this technique is to keep the hammer in contact with the string indefinitely. This technique and its control are not used in the production of music discussed later in this chapter. A more extensive discussion of this technique and its musical implications can be found in chapter 5.

The modified instrument evolved with no individual string dampers. As a compromise, an autonomous damper mechanism was installed for the bass and middle register string groups on the instrument. Operating under separate control, the damper mechanism can be activated while strings are being struck. An unusual pitched drumming effect results. This was used as a feature in Variations, discussed in the section 3.5.

Due to the simplicity of operation, the action in the modified instrument can be activated very quickly. Single solenoids have maximum repetition strike rates approaching 30 per second. However, this technique has never been fully exploited in a single composition. The difficulty with it was that when a number of solenoids were operating at these rates, their performance became degraded because data could not be transmitted to each of them fast enough from the microcomputer. With such a volatile environment, a single solenoid oscillating at such a rate needs to be carefully controlled; otherwise, the brilliance of this effect is lost. These high repetition rates are enough to generate an audible secondary tone, however, little research has been undertaken to discover its potential in a musical application.

3.4.2 The Traditional Piano in this Performance Context

The traditional piano is obviously not capable of being exploited to the same degree under microcomputer control with the normal upright hammer action. This restricts the operational speed at which the microcomputer can drive the hammers. Nevertheless, it is possible to operate at a rate which is quite fast and just under the action's failure point. During such repeated attacks of a given note in the upper register (top octave and a half) of the instrument, a certain percussive characteristic emerges in the overall sound. This percussive component in the sound can be quite dominant, although it depends on the general level of note actvity on the instrument.

Although this phenomenon is of little musical value, it illustrates a point about extended performance. In a similar manner to the modified instrument, operation taken to extremes often produces unpredictable results that may or may not be aesthetically valuable. Any such aesthetic value, of course, will largely depend on how it occurs in a musical context.

On a more conventional level, the performance system enabled the traditional piano to perform with remarkable subtlety. With careful adjustment the piano can perform complex and extremely active passages without an obtrusive mechanistic character. The inherent mechanical operations can be smoothed over through attention to phrasing and dynamics. Music that is beyond human physical interpretation can be given those human performance characteristics of tempo variation and accenting in any combination within the range of possibilities available from the system.

While the score can contain these subtleties it is, nonetheless, extremely tedious to mould the data into the desired musical result. The tedium could, theoretically, be reduced by using a system with an quicker turnaround time in the edit/rehearse cycle. This would include the means to readily identify the parameters requiring adjustment and not taking a hit or miss approach when adjusting the complex array of variables.

3.5 A Compositional Application

Although the software is not sophisticated by current standards, in 1984 it allowed a unique degree of flexibility for a small system. With familiarity and diligence, music of considerable subtlety could be produced. It was not difficult to establish a practical edit/translate/perform cycle for the refinement of musical ideas, just tedious to pursue an acceptable result.

Three works were produced using the system: Atlantic Fears (1983), Fantasie (1984) and Variations for Two Instruments (1984). The only one, however, to use both instruments simultaneously is Variations. It appears on the accompanying tape and the score can be found in appendix D. The form of the work is shown in section 3.5.1.

Variations for Two Instruments, written in 1984, was the first work to explore the possibilities inherent in a simultaneous performance of the instruments under microprocessor control. It is also the only work for both instruments in which the organisation of the simultaneous parts was rehearsed and optimised for the best effect.

The concept of 'variation' in this work is treated on two levels:

1. Sequential variation of material.
2a. Parallel variation of material that although different is derivative, i.e. melodic and rhythmic juxtaposition.
2b. Identical material performed with temporal dislocation, i.e. small delay between instruments.

The first level is where the variations themselves (7 variations on theme A in part I and 6 on theme C in part III) are presented sequentially. This is the most obvious interpretation of variation. In Part I, the modified instrument also presents the thematic material in counterpoint against a rhythmic motive which is identical to the rhythm of the thematic material. This parallel contrast of near similar material from the single instrument forms the first of two aspects of the second level.

The timbre of the rhythmic section in part I (a pitched drumming effect, achieved by striking damped strings) is unique to the modified instrument. Here the instrument is displaying extreme contrasts in its behaviour through the concurrent use of muted attacks and free resonance.

Part II functions as a bridge and also serves to introduce the second instrument, theme B and C. Theme C is the principal theme of part III.

In part III both instruments perform simultaneously. While part I contrasted material using one instrument, in this part, the second level is a contrast between the instruments. This is the second aspect of the second level. Theme C is present at all times in this part, either in its melodically recognisable form or in the percussive interpretation.

Variations 2, 5 and 6 of part III demonstrate a unique phenomenon of this instrumental arrangement. In these variations a temporal dislocation is achieved by delaying one of the instruments against the other. The effect is similar to a subtle echo or reverberation. Although the instruments are timbrally different the effect is most noticeable in variations 5 and 6 where they are both playing the same thematic material. This is the second aspect of the first level, that is, variation by temporal dislocation.

The work ends (closure) with a farewell hocket of the parts of theme B from each instrument in between short percussive fragments.

3.5.1 The form of 'Variations for Two Instruments' (for two instruments)

MI = Modified Instrument (1st instrument in order of appearance)
TP = Traditional Piano (2nd instrument)

Part I

(MI solo Variations on the percussive motive and theme A)

1 - Percussive motive
2 - " " in lower pitch. Louder
3 - " " + theme A. Damped
4 - " " + " " Undamped
5 - " " + " " Damped. Theme extended
6 - " " + " " Undamped. Theme extended
7 - " " + " " in octaves. Undamped. No extension

Part II (Bridge)

(Introduction of TP and themes B and C)

Percussive motive
MI theme B. Damped
MI theme B. Undamped
Percussive motive with both parts of theme C
Percussive motive (solo)
Percussive motive in treble register with theme C

(first appearance of TP)
TP interprets percussive motive and theme C
TP theme B
TP theme C in bass register
MI theme B (variation of original theme B)

Part III

(Variations on theme B. Instruments perform simultaneously)

1 - MI damped rhythm of theme B
- TP theme B

2 - MI damped rhythm of theme B
- TP theme B
(One instrument is delayed against the other)

3 - MI theme B
- TP theme B
(Simultaneous performance of theme B)

4 Same as 3

5 - MI theme B
- TP theme B
(One instrument is delayed against the other.
The effect is noticeable in stereo)

6 Same as 5

MI percussive motive
MI first part of theme C
TP second part of theme C
MI Concluding percussive motive

Tile Page | Acknowledgements | Abstract | Contents | Examples
Introduction | Chapter 1 | Chapter 2 | Chapter 4 | Chapter 5 | Conclusion
Bibliography | Discography | Appendices