Chapter 4

A REAL-TIME ALGORITHMIC COMPOSITION SYSTEM

In this chapter, an algorithmic composition and performance system for the microcomputer controlled instruments is described. This system evolved through a greater awareness of the power of algorithms and a curiosity about how well they would function in a real-time performance situation. The chapter covers aspects of algorithmic composition found in the general computer music literature and then details the function and operation of the system. Finally, the second work on the tape which was produced from the system is discussed. A listing of the system software written in PASCAL can be found in appendix F. Performance data and the state machine used to generate the work, A Tale from Transitions, can be found in appendix D.

4.1 An Algorithmic Direction

In the system discussed in chapter 2, the data handling and composer/machine interactive features were distinctly retrospective in outlook. The overall operation was reminiscent of some of the earlier non-real-time mainframe computer music applications (Music 4BF and Music V). Apart from the obvious processing/performance limitations, the structure of the score data, together with the inability to modify essential aspects of the score without a tedious edit/translate/perform cycle, discouraged extended or ambitious rehearsal of material. Some responsibility for the outcome of the system is attributable to a conventional view of composition which holds that the composer is responsible for all musical minutiae. In this respect, most computer music software reinforces this view, in spite of the fact that part of the composing process may be delegated to the computer under the composer's supervision. While this is currently the emerging trend, it took computer music environments such as that described in chapter 3 to identify needs and possibilities for future systems.

In the previous performance system the requirement that the performance data remain resident in memory was a clear indication that the limits of the system would be reached before very long. The brevity of the compositions, especially acute when the music or instrumentation became complex, emerged as one of the principal drawbacks to that particular approach to producing music.

The limitations impacted on the microcomputer's two essential resources; memory and the microprocessor (CPU). The result was that the production of larger, more complex works was exceedingly difficult, if not impossible. Given the design specifications of the musical system, this was not entirely unexpected. An examination of how the performance data are referenced by the system should serve to illustrate the point.

The Z80 microprocessor has 16 bit memory addressing. From within a program and without special extended addressing capabilities, it can only address 65,535 memory locations. Files of 64K bytes therefore appear to be the maximum size possible. There are ways around this limitation and the newer 8 bit processors have on-chip extended addressing up to 256K. However, the system under discussion here does not have that feature.

To further restrict the size of performance files there was another limitation imposed on the system. The programming language used (BASIC) defined integers to be in the range of -32,768 to 32,767 (This is, in fact, the standard with most languages for 8 bit microcomputers). Integers are used to index into the static array data structure which contains the performance data. Since only positive integers are used, the maximum number of array elements (memory locations) accessible is reduced to 32,767. Negative numbers cannot or should not be used to access array locations. In any event it would have been bad programming practice to attempt to do so. This further limitation became a constant concern as the size of the score files grew and the translated performance files reached and occasionally exceeded the 32K limit with disastrous consequences.

The composition of longer works was therefore restricted by the microprocessor's inability to utilise a larger memory space. The worst case occurred when the composition used the two instruments simultaneously. Not only was the duration of the work reduced but the performance could be affected by the overhead of transferring the data to both instruments. In conjunction with a general increase in programming skills, the previous system per se provided the impetus to examine other composing strategies.

4.1.1 Algorithms and Music - A Brief Perspective

In 1973, the computer scientist Donald Knuth wrote:

It has often been said that a person doesn't really understand something until he teaches it to someone else. Actually a person doesn't really understand something until he can teach it to a computer, i.e. express it as an algorithm... The attempt to formalize things as algorithms leads to a much deeper understanding than if we simply try to understand things in the traditional way. (Knuth 1973. p.709)

An algorithm can be briefly defined as "a prescribed set of well defined rules or processes for the solution of a problem in a finite number of steps" (Sippl 1981. p.16).

Although Knuth's statement has an air of generality about the role of algorithms, his early perspective was that of a mathematician and as such did not specifically address the issues in an artistic or creative context. His famous multi-volume set, The Art of Computer Programming (Knuth 1973a, 1973b, 1981) and such articles as Algorithms (Knuth 1977. pp.63-80), made it clear that the focus of his attention was primarily on the theoretical and numerical application of algorithms. This may have changed somewhat in recent years with his involvement in computers and typesetting (Knuth 1986). Nevertheless, the strength and clarity with which problems can be expressed and solved through the use of algorithms is a powerful incentive to apply them in an artistic and experimental context.

The application of an algorithmic approach to the formalisation of aesthetics has been suggested by Stiny and Gips (1978). Such an ambitious attempt to apply algorithms may be fraught with many technical, as well as philosophical problems, but it nevertheless challenges the general belief that aesthetics can only be understood in terms of the subjectiveness and vagaries of personal taste and social mores.

A first impression of the effectiveness of algorithms tends towards doubt when confronted with the complexities and abstractions of the human creative process. For Knuth's problems and the bulk of commercial and scientific computing applications, algorithms are the key to performing important and necessary tasks. Their operation is ideally suited to the nature of those classes of problems. In recent years, however, artificial intelligence concepts and practices have made effective contributions to the issues of human and machine cognition, reasoning and creativity (Duisberg 1984; Roads 1980), thus shifting the emphasis away from the notion of a rigorous mechanical sequence of operations implied in the term 'algorithm'.

The term 'heuristic' (Vermuri 1978. pp.88-104) - in which there is a searching and learning process embedded in the approach to finding a solution - has considerable appeal to those involved in automatic composition. A connotation implied by heuristics is that an automated (algorithmic) composition system will be significantly improved by the implementation of heuristic strategies.

Heuristics offer the approach to a solution through searching and critical evaluation of the possibilities, with the weaker ones being eliminated as stronger candidates are found or created. The process is unpredictably long and usually implies non-real-time music unless considerable computing power is engaged or some other strategy employed, i.e. the searching algorithm terminates after a certain period of time, regardless of whether the best result is found. Perhaps as the computational and I/O throughput power of microcomputers continues to increase, the full implication of heuristic composition will yet be appreciated across a larger base of computer music composers.

Of course, underlying heuristic operation are algorithms. Algorithms simply perform a series of operations from beginning to end. However, as there is a fundamental difference between the concept and application of algorithms and heuristics, so too are there differences in the processes of creativity. While the more intelligent strategies offered by heuristics may appear desirable in a composition program, the sophisticated use of algorithms alone may also yield some interesting results under appropriate conditions.

The precedents for algorithmic composition processes date back to the beginning of computer music. The seminal monographs of Lejaren Hiller and Leonard Isaacson (1959), and Iannis Xenakis (1971), detail early approaches to computer generated music. At first, computer output was transformed into a score for musicians to play. The software and hardware were not available to directly synthesize the data or allow transmission to external hardware for realisation into sound.

The fundamental techniques employed in the algorithmic generation of music or musical scores have not changed a great deal over the years with the exception of non-linear mapping. Various probability algorithms (Lorrain 1980; Moorer 1972), nth order Markov processes (Jones 1981; Moorer 1972; Pinkerton 1956) and other stochastic systems (Ames 1987a, 1987b; Jones 1981; Lorrain 1980) are still relevant today. The emphasis now, however, is towards implementation and use of microcomputer systems. The current direction in computer music workstations is for real-time generation and modification of musical material from an icon based graphic display, with the option of performance at any point in the composing process.

The algorithmic approach to music composition and performance has evolved through a number of schemes. At either end of the spectrum are perhaps the following two examples, some 25 years apart. In the 1950's Hiller and Isaacson (Hiller and Isaacson 1959) employed a traditional contrapuntal approach in the construction of the Illiac Suite. The Illiac Suite was generated and eventually scored for string quartet. Some twenty five years later, Christopher Fry's (Fry 1984) generation of more exotic musical phrases in Flavors Band - a language he developed for specifying jazz and popular music styles - was produced on a Lisp machine. This dedicated artificial intelligence computer generated the output which was then realised on a synthesizer connected to the system.

In more recent times, Intelligent Music's M and Jam Factory (Zicarelli 1987) and HMSL (Hierarchical Music Specification Language) from the Mills College Center for Contemporary Music (Polansky, Rosenboom and Burk 1987b) have fused interaction with algorithmic composition in a MIDI context, providing a very powerful system for the Apple Macintosh and similar microcomputers. This brings to the microcomputer user the sort of sophistication never dreamt of in the late 1950's but which is now taken for granted from AI workstations.

Although the Hiller and Fry examples illustrate technological advancement and stylistic diversity over the years, one aspect that remains both fundamental and critical to algorithmic composition is the selection and generation of the various atomic elements and structures which constitute the work. Generating this material can be a matter of chance or quite deterministic on the composer's part. Ultimately the computer must take some role in producing the music but the extent of this role is variable.

A discussion of algorithmic composition would not be complete without mentioning the use of non-linear mappings, and in particular, a branch of non-linearity called 'fractals' (a geometry based on fractional dimensions). An overview of the history, characters and concepts from the scientific community where this field of study has had the greatest impact can be found in Gleick's book, Chaos (Gleick 1988).

Benoit Mandelbrot, who is regarded as the 'father' of fractals, has significantly influenced contemporary thought with his work. His original research (Mandelbrot 1982) into the description of shapes that tended to defy the application of standard geometry and calculus led to the remarkable observation that certain structures contained the property of 'self-similarity'. Viewed from various stages of magnification these structures appeared primarily the same.

In the musical domain, research and experimentation is being undertaken by increasingly more composers and reference to this field of algorithmic composition is appearing with greater frequency in the literature (Bolognesi 1983; Fagarazzi 1988; McNabb 1986; Polansky, Rosenboom and Burk 1987b. pp.226-27; Pressing 1988).

The implications for music are in the potentially interesting generation of musical design and instrumental timbres. In discussing the mapping of 1/f noise to pitch or rhythm, Michael McNabb observed:

Indeed, melodies generated this way do sound more reminiscent of composed music than those generated with other kinds of random functions. I am not sure about 'pleasing', but it definitely has the right kind of shape and sounds somehow 'intentional'. (McNabb 1986. p.152)

Further on he states:

The fact that fractal properties are common to music across such a wide range of cultures and times at least suggests that there is physiology-based common ground for musical aesthetics. (McNabb 1986. p.152)

There is now considerable interest in this composing strategy and it is not difficult to implement on microcomputers. The successful generation of interesting music will, however, largely depend on what functions are used, what they are mapped to and whether other constraints are applied to the generated values, i.e. probability weightings and rule-based schemes.

The development of an algorithmic system maybe viewed as being dependent on three factors:

  1. The degree of stochastic or non-linear mapping processes.
  2. The application of formal representations for music, Grammars, Augmented Transition Networks, Neural Nets, etc.
  3. The degree to which the composer or performer is directly involved in manipulating the musical result.

Figure 4.1 presents a graphical view of the three factors in which the relationship of each factor can be adjusted against the others in order to complete the functional make up of an algorithmic system. Any such adjustment to a particular factor must impact on one or both of the other factors. To plot the location of a system, each of the three components should be estimated as a percentage of the total system. This might be done by determining the proportions of the software dedicated to each factor and adjusting this by considering each factors contribution to the system as a whole. Although only approximate, an increase or decrease to one of the factors must involve the inverse operation to one or both of the other factors. Thus through a series of substantial modifications the desired changes to the system could be plotted. Figure 4.1 by no means covers all the complexities of algorithmic systems but it does provide a means of understanding the relationship between the principal factors.

Fig. 4.1 The current system plotted as a function of stochastic or non-linear mapping
processes, formal representations of music and direct human influences.

4.2 Algorithmic Composition for the Acoustic Instruments

The temptation to explore the domain of algorithmic composition grew from the above observations and a general awareness of the microcomputer's operational characteristics and suitability to the task. Through the use of a different programming language, PASCAL, the undertaking was further simplified. In fact, it was soon realized that the potential was there for interesting results without resorting to extremely expensive equipment and complex programming environments.
An algorithmic composition system for the electro-mechanical instruments has some advantages over electronic synthesis systems, in that the microprocessor is not required to generate the fundamental sounds in competition with the composing and I/O management processes. This is also the case for external synthesis equipment which similarly need not burden the host microprocessor. However, such equipment does require a greater volume and complexity of data to be transmitted from the computer in order to configure and activate the respective devices. External synthesis units and samplers tend to require large amounts of complex data to be transmitted in order to exploit their inherent potential. The acoustic instruments, on the other hand, require fewer data to represent the music simply because the inherent character of the instruments provides the necessary 'interest' component to the sound. In an algorithmic system for acoustic instruments, computational time and resources can be focused on generation of the composition rather than timbral or sonic diversity.

The system discussed in this chapter is dependent on composer determinism in the early stages of the composition's creation. There is therefore no low level algorithmic event generation. It was felt that the microprocessor, in dispatching the dual real-time operations of composition and performance, might be detrimentally burdened by a plethora of low level compositional algorithms. The selection and organization of the events (notes) into a hierarchy of structures, which eventually form the composition, was deemed too low level and hence too time-consuming to meet the performance criteria. Instead, a compromise was found which offered the optimum real-time processing to performance ratio in a strictly serial processing operation. This ratio enables the system to process and perform composition fragments, without any noticeable delay between them.

As it eventuated, the size and complexity of the total system required it to be two separate subsystems which function as two stand alone programs. These subsystems were written in the PASCAL programming language and the code is listed in appendix F.

The first subsystem, called LOATESS (LOad And TEst SubSystem) is used to initially create performance data and provides the necessary data manipulation facilities (Figure 4.2). Functions for the management of the musical elements include: inserting, modifying, deleting, moving and copying as well as a modest performance functionality for auditioning the current material. File management functions consist of save, restore and erase. Concatenate, superimpose and other higher level operations were considered for inclusion in LOATESS (and some partly implemented) but the physical limits of the microcomputer were reached and so prevented this. These functions hinted at interesting possibilities for the rapid and subtle manipulation of data. But in light of the fact that the data is to undergo considerable processing prior to performance, much of the anticipated benefit of these functions may have been difficult to assess and perhaps in the end, unnecessary.

Fig 4.2 A block diagram of LOATESS (* not fully implemented due to lack of
memory).

The primary function of the second subsystem - PERSSYS (PERformance SubSYStem) - is to organise and perform the musical material in real-time (Figure 4.3). PERSSYS is similar in both appearance and function to LOATESS. Although it supports limited data examination facilities it cannot edit the data. A detailed account of PERSSYS and its operations appears in later sections.

Fig. 4.3 A block diagram of PERSSYS.

The real-time generation of music from this system can be viewed more appropriately as an improvisation based on a finite set of quasi-structured material. Given the nature of each structure and how it is interpreted and performed, it is virtually impossible that a consecutive interpretation of the same structure will result in a direct repetition. Furthermore, the probability that two performances of the same number of structures will be identical is extremely low. Repeated performances do tend to sound similar due to the nature of the material, but each nevertheless has its own character.

The unique character of a structure can be understood and appreciated in isolation during the LOATESS phase but in the context of a performance this character can vary from insignificant to memorable to overpowering. Such is the effect of the material around it or it on the surrounding material. The performance algorithms in PERSSYS modify structures throughout the course of the work and therefore the character of each structure changes. Drawing on a limited stock of structures, the resulting effect is music which is vaguely repetitive and circularly cohesive.

The modular representation of the musical material excludes it from the class of complex composition systems that organise the music through the use of grammars (Duisberg 1984; Moorer 1972; Roads 1980, 1985). Although the use of probabilities in PERSSYS promotes a level of association between nascent structures, no long range structuring mechanism is in operation and as a consequence the concatenation of structures has tended towards music of an indeterminate form. This observation is based upon a relatively brief use of the system with a limited variety of structures. It is possible that through very careful creation and organisation of structures a performance with a more intentional form might result. Something like an extended English Rondo form (A B A C A, etc) or one of the interpretations of the theme and variation form comes to mind.

The duration of a performance is determined by the number of structures or states to be interpreted and in terms of common time, can only be estimated by extrapolation from previous performances.

4.3 The Nature and Organization of the Musical Material

The representation of musical material is largely the result of technical expediency imposed yet again by the limitations of the microcomputer. Uppermost in the consideration of the design and coding of the structures was how to obtain the most efficient form for data access and management. The question was eventually resolved by the imperative of processing efficiency. While it is possible for the composer to work around certain limitations in the musical structures, it is not possible for the microcomputer to overcome the inherent processing overheads.

Central to the function of this system is the concept of an event structure (Figure 4.4) which is defined as a static collection of events. It formally exists as a PASCAL record of 5 elements of which 4 are arrays and the fifth element indicates how many events are in the event structure (Figure 4.4). The arrays contain the information for each event in the structure. The system can theoretically accommodate up to a maximum 32,767 event structures, however, such an extreme number is completely impractical and the current system sets the default maximum at 40. This could be changed if required. A composition is thus collection of event structures. This is commonly referred to as the event space:

When a stochastic structure is applied in musical composition, it is necessary to define an event space over which it operates. An event space is an ordered set of events that may consist of a natural sequence of common musical material such as the notes in the major scale of C, individually defined complexes, selected natural sounds, or whatever basic compositional elements a composer may require. The order of an event space is the number of events it contains. (Jones 1981. p.46)

The event structure has musical significance only when performed. In its quiescent state, there is little indication what the performance of the structure will be in musical terms.

event structure =
record {Default length is 20 for all arrays}
Length of the event array
An array of event intervals
An array of start times for each event
An array of durations for each event
An array of dynamics for each event
end

Fig. 4.4 The form of an event structure in PASCAL pseudo code.

In this case, however, the event structures contain the important elements and therefore are not the lowest musical entity. Since the event structures are the only objects controlled by probability, the notion of an event space must be adjusted to consider only the event structures. The term 'event structure space' is in this instance more appropriate.

The idea for an 'event structure' came from the concept of the 'aggregate' structure described earlier in association with Nancarrow's work (section 1.4.2). The event structure, however, is not self-contained and is subject to interpretation and modification throughout the performance; it may appear many times, each different from the last. It also shares some similarities with the notion of an improvisation based on a pool of motivic cells or musical fragments. Finally, there is even an element of musique concrète about the overall treatment of the event structures as sound entities. Sometimes during the performance event structures coalesce seamlessly, while at other times, they overlap each other like a collage.

An event is defined as the performance of one of the discrete collection of elements in an event structure. As with the event structures, there is also a theoretical maximum limit of 32,767 events. The default is set to 20. In its static form an event has four parts:

1 - A number representing an interval to be defined at during the performance
2 - A start time
3 - A duration
4 - A dynamic

These four elements appear in the event structure after the even structure length field (Figure 4.4).

LOATESS provides a framework in which the events are placed and considered in the context of the structure. The actual pitches of each event structure are not known until the structure is accessed during performance, as a consequence, events are described in terms of their interval relations. In LOATESS the first event is generally defined as zero with the other events numerically referenced to it. Each event has a start time, overall duration and dynamic. Groups of events or even the entire structure itself, can form any of the usual musical structures, i.e. chords, counterpoint, melodic lines and arpeggios.

When preparing these structures, careful consideration must be given towards their intended purpose in the context of the performance. It must also be borne in mind that the computer will make the final decision in the selection of structures and then may considerably alter the nature of the material itself. Therefore, the structures should not be too self-contained, for example, possess prominent beginnings and endings. Neither should there be a predominance of material that is intensely distinct. Ideally, the structures need to be malleable and vary in dramatic content. In this way they can be joined seamlessly to one another yet provide the diversity necessary to maintain interest.

4.4 The Function of the State Machine

The mechanism that selects which structure to use next is known as a 'state machine'. Its sole purpose is to determine what to do next based on the currently executed event structure. State machines can be found in compilers, syntax analysers and communications software, to name a few applications.

In this instance, the inspiration for the state machine came from a professional encounter with Data General's X.25 data communications software (Data General 1985). This system uses a state machine to manage levels 2 (data link) and 3 (network) of Data General's implementation of the lower levels of the ISO reference model (Tannenbaum 1981).

The state machine in this musical application implements a simple first order Markov process, with the sequences of transitions defining the Markov chain. It is a first order process because the probability sequence only extends back one state or generation.

More sophisticated control mechanisms may be constructed by using a Markov chain that takes into account the context of a sequence making the probability of its occurrence depend on the event that preceded it. In this way a matrix of probabilities over an event space may be built up. (Jones 1981. p.46)

In this musical application - quite different from that of communications - the state machine operates the selection process for the next structure on the basis of the previous structure selected. How the state machine does this can be briefly explained as follows :

- Each event structure has a unique numerical identifier. The first operation of the state machine is to access a table of all the event structure identifiers (see end of Example 4.1). When the entry corresponding to the current event structure is found, the next phase (procedure) of the state machine is entered. Here there is an algorithmic process which determines the next structure.
- The process functions by randomly accessing a table containing the numerical identifier of the new structure.

- The operation of selection at this point can be considerably influenced by the composer. Organisation of the entries in the table can represent every possible structure once or be weighted in favour of one or more structures at the expense of others. For example, if there are ten entries, five of them could reference the same structure while the other entries are unique. If there were in fact more structures than entries, some structures would never get selected.

Once the structure has been selected the individual events will undergo further processing before being sent to one of the instruments. This modification process is discussed in section 4.5.1

Example 4.1 shows the mechanism for selecting a structure written in the Pascal programming language. An explanation of this code follows the example.

procedure Select_Structure (var i : integer);
{
N.B. The procedure block for Select_Structure is at the end of this example.

Structure Selection
~~~~~~~~~~~~~~~~~~~
}

procedure From_struct_1 (var i : integer; n : integer);
var
choices : integer;
begin
choices := 4;
case random(choices + 1) of
1 : i := 3;
2 : i := 2;
3 : i := 4;
4 : i := 5;
end;
end;

procedure From_struct_2 (var i : integer; n : integer);
var
choices : integer;
begin
choices := 4;
case random(choices + 1) of
1 : i := 2;
2 : i := 4;
3 : i := 1;
4 : i := 3;
end;
end;

procedure From_struct_3 (var i : integer; n : integer);
var
choices : integer;
begin
choices := 4;
case random(choices + 1) of
1 : i := 4;
2 : i := 1;
3 : i := 3;
4 : i := 2;
end;
end;

procedure From_struct_4 (var i : integer; n : integer);
var
choices : integer;
begin
choices := 4;
case random(choices + 1) of
1 : i := 1;
2 : i := 5;
3 : i := 3;
4 : i := 4;
end;
end;

procedure From_struct_5 (var i : integer; n : integer);
var
choices : integer;
begin
choices := 4;
case random(choices + 1) of
1 : i := 5;
2 : i := 1;
3 : i := 2;
4 : i := 4;
end;
end;

procedure From_struct_6 (var i : integer; n : integer);
var
choices : integer;
begin
choices := 4;
case random(choices + 1) of
1 : i := 6;
2 : i := 6;
3 : i := 1;
4 : i := 6;
end;
end;

begin { Select_Structure - This is where the State Machine is first entered }
case i of
1 : From_struct_1(i,i);
2 : From_struct_2(i,i);
3 : From_struct_3(i,i);
4 : From_struct_4(i,i);
5 : From_struct_5(i,i);
6 : From_struct_6(i,i);
end;
end; { Select_Structure }

Ex. 4.1 A simple structure selection mechanism with 6 structures.

The selection process begins with entry into the begin/end block identified as Select_Structure. 'i' is the current structure and in this example it will be in the range of 1 and 6. The From_struct_n (where n is the event structure) statements are calls to nested procedures that do the actual selection.

The From_struct_n procedures contains a call to the random number generator which returns a value that points to a statement assigning 'i' the new structure identifier. This algorithm may seem unnecessarily convoluted and where a large number of structures are concerned, verbose and bulky. But it was designed to allow simple visual identification of the functionality and a convenient format for alteration.

It was stated earlier that a design principle had been to admit as much composer determinism into the system as was possible with the resources at hand. What tempered this design philosophy to some extent was a curiosity towards the system's capacity to generate interesting moments over and above the nature of the musical fragments per se. As a consequence of this dilemma, a hierarchical position was adopted where the composer's influence is exerted over the probability of events occurring as opposed to guaranteeing their occurrence.

Changing the probability of the selection process is simply a matter of changing the number of case statement entries in the From_struct_n procedures. Structures can also be recognised or ignored by adding or subtracting entries in the case statement list in the main block of the Select_Structure procedure.

The disadvantage with this approach is that it cannot be altered in real-time or for that matter without re-compiling PERSSYS. Such functionality exists in Jam Factory (Zicarelli 1987. pp.23-27) and HMSL (Polansky, Rosenboom and Burk 1987b) where the sophistication of the Macintosh microcomputer permits the use of interactive screen management to change the nature of the transition tables as represented in:

The probabilistic decision is based on a bar graph which can be manipulated directly by the user while the algorithm operates, allowing a fine tuning of its performance. (Zicarelli 1987. p.24)

It should, however, be pointed out that due to the physical limitations of the microcomputer, PERSSYS could not have evolved along the lines of an 'interactive composing' system as described and developed by Joel Chadabe (1984), and Chadabe and Meyers (1985) or the contemporary systems of M and Jam factory described by Zicarelli (1987).

4.5 The Performance Algorithms

A performance takes place when a number of event structures are processed and output to the instruments in real-time. A performance could therefore be theoretically the continuous performance of anywhere between 1 and 32,767 structures and may last several hours. Extending the performance time on the limited microcomputer was a significant step although it meant repetition of fundamental musical material.

The state machine provided the mechanism for selecting structures in their 'raw' form. What was further needed was real-time processing of this raw data and its placement in context with the previous structure. Several algorithmic strategies were used to achieve this. Figure 4.5 shows the iteration loop for the processing of a structure and the performance of a state at the highest level in the program. 'Natural end' refers to the absolute conclusion of the performance, i.e. when the sound ceases, not simply the initiation of all the events. This is particular important for the traditional instrument which must actively sustain and then finally release the notes.

PERSSYS entry point:

Which state initiates the composition?
How many states will be performed?

While not the natural end and count is not equal to number to perform
Begin
Select the structure to be processed
Determine the reference pitch for the structure
Select the function that will modify the structure
Apply the function, manage queues and control event scheduling
Output to the instrument
count := count + 1;
End

Reset the instruments after the performance

Fig. 4.5 A pseudo code representation of the main loop for structure performance.

4.5.1 Structure and Event Transformation Functions

The original intervallic order of events in a structure can be transformed. Since the system is dependent on so few structures, transformation of events is necessary to provide pitch and intervallic diversity while, maintaining at least in theory, a sense of cohesion throughout the composition.

The functions are those traditionally used in serial composition: inversion, retrograde and retrograde/inversion. Other functions were considered for inclusion, for example, concatenation, partial merging, superimposition and various other forms of interpolation and would have been implemented had not the size of the program again reached the system's limits. It was also felt that increasing the number of transformation functions acting on the structures would necessitate a higher level structuring of the composition and inevitably the entire process per se. Since a major rewrite of the system was not imminent and the microcomputer's resources were again stretched, it was a moot point as to whether a few extra functions would significantly improve the musical result.

The operation of the three functions can be found distributed in procedure out. The functions are active on individual events between the queue examination phase and output operations (Figure 4.6).

While Performance is still in progress
Determine which instrument is to receive the event.
Examine the events on the queue.
If there is an event
Then process event and output it to the instrument.
Else increment the time count and enter loop again.
End.

Fig. 4.6 A summary of the main loop structure of procedure out.

The set functions, inversion, retrograde and retrograde/inversion are interwoven with other operations of the performance in progress. Although the inversion function requires more computational time than retrograde, which is simply the events accessed in reverse order, any resulting delay through the system may well be absorbed by the nature of the performance.

4.5.2 Performance Architecture and Structure Continuity

Although the Markov process selects structures on the basis of probabilities somewhat pre-ordained by the composer, additional processing was felt necessary to integrate them into the performance context. This process of integration is not part of the initial selection of the structure. Some benefit might have been gained from using higher order Markov processes (maintaining a longer history of states) or creating extensions to the simple model as has been suggested by Kevin Jones (Jones 1981. pp.48-60). The approach taken in this instance, however, might be regarded as an extended first order Markov process.

The 'extended' functionality lies in the character of the event structure. An event structure can be thought of as incomplete. The information that it contains gives little indication of the myriad of interpretative possibilities it may assume at the time of performance.

In the description of a structure it was mentioned that events are defined in terms of intervals above some reference pitch and not simply pitches in their own right. The first event is usually zero although it technically can be any number in the practical range. Making the first event zero does, however, provide a means of understanding the structure as a vertical entity, that is as something built up rather than out from some internal point. It is also much simpler to invert the structure when the first event is the mirror point.

When the structure is performed, the interval values are summed to a value called the base value (reference pitch) which is generated from a pitch contour algorithm. The first event interval will become the pitch corresponding to that numeric value. The procedure ref_pitch maintains the pitch contour (see Figure 4.7) used in generating the value and also decides where and when it is time to change direction. The function gen_event adds the base value returned from the procedure ref_pitch to each interval in the event structure.

Because the maximum and minimum range of pitches within the structures is unknown, it is difficult to determine whether addition to the base value will result in pitches out of the instruments range. Consequently, base values are generated from numbers less than 62 and greater than 19.

Figure 4.7 is a graph of what a reference pitch contour may look like for a section of a performance. The states are plotted irregularly to reflect the arbitrary duration of event structures during performance. Direction is an important aspect the contour as it gives structures locality without stasis.

The reference pitch contour is one of a number of operations that function at a conceptually higher level and at performance time. By maintaining a pitch contour, structures will tend towards a controlled and focused presentation rather than being unnecessarily scattered throughout the instrument's pitch range.

Fig. 4.7 A graph showing a possible reference pitch contour for a section of a
performance.

4.5.3 Event Durations and Tempo

Each event in the event structure has a default duration which is allocated by the composer at the time of the structure's creation in LOATESS. As a consequence, the structure possesses an inherent tempo character which remains evident, to some extent, even when the duration values undergo modification during the performance. If the majority of the events in the structure have similar durations then the structure as a whole will reflect tempo changes more dramatically. For example, if the majority of events have large duration values the tempo will generally be slower in comparison with a structure of primarily shorter durations. In a more complex example, a mixture of long and short event durations would give the structure a distinctive rhythmic character. Such a structure tends to give the illusion that a number of structures are being rapidly performed in succession and it also, to some degree, obscures structure transitions.

It is possible to construct polytempi and polyrhythmic structures in LOATESS. Because of local adjustment and instrumentation, their exact effect during a performance could not be clearly anticipated. However, to make some rhythmic character distinct it would perhaps be necessary to create a number of structures that shared the same rhythmic characteristics. Thus when a sequence occurred, the rhythmic character would continue across new structures.

There are three possible tempo modes: accelerando, ritenuto, and l'istesso tempo. In the first mode, the tempo is gradually increased from that of the previous structure. In the ritenuto mode, the tempo is gradually decreased, and with l'istesso, the tempo remains unchanged. Under the distributed algorithmic approach, a new mode is selected only after a certain number of structures have been performed and not simply when a new structure is selected. Irrespective of what structures are chosen, a section of the performance can have a certain character simply because of the common tempo mode.

A tempo mode is active for between 1 and 5 states. If the tempo mode is accelerando, for example, then each consecutive structure will be adjusted to perform in a proportionally shorter period than the last. To do this a number representing the proportional adjustment is subtracted from the original duration values defined during the LOATESS stage. On each new state the proportional value is increased to shorten the original duration. In a similar manner, the process works for the ritenuto mode. For the l'istesso mode the previous value and the proportional value are simply added (there is no increase) so the tempo remains the same.

The maximum possible duration value for a note is again 32,767 but for most practical purposes the range is between 15 and 10,000. The tempo mechanism including the queuing strategy can be found in the function tempo located in procedure out and also in the main section of procedure out itself (see appendix F).

The actual timing of events is determined by the processing of the while loop in procedure start. Every time the loop is executed the value of the variable 'time' is incremented. Although this registration of time is not exact and can vary depending on the computational activity within the loop, it is relatively efficient and does not severely burden the system.

4.5.4 Dynamics

Event dynamics are taken directly from the event structure. In the current system, no further processing is done to them. Although the full range of the 32 dynamic levels could be put to better effect in strictly controlled conditions, it was considered that the extra processing required to manage this aspect of the performance would at the time be unwarranted and difficult to incorporate into the already large program. Event dynamics therefore, remain unchanged from the time of their insertion into the structure during the LOATESS application.
Rather than pursue the development of more sophisticated algorithms to control both the distribution and balance of dynamics between the instruments, it was felt that a variety of instrumental textures during the performance might sufficiently compensate for the lack of dynamic subtlety. This is, of course, dependent on the organisation of durations in the event structure, so a distinct contrast of sparse and dense instrumental texture does occur. The limitation with this approach is that it excludes the possibility of dynamic contrasts in continuous and dense passages of music.

4.5.5 Instrumentation

Both instruments are active during a performance. There is unfortunately some overhead in managing the data for both because of their opposing mechanical operations (see section 2.3.2 in Chapter 2).

When consideration was given to the distribution of events among the instruments, no particular strategy appeared ideal. More sophisticated strategies naturally involve substantial computation time. A more 'intelligent' approach would also have increased the size of the program, further burdened the processor and may not have enhanced the performance to any great extent. Therefore, from a pragmatic perspective, it was finally decided that a random distribution of events was just as interesting and involved very little processing.

It was relatively simple to implement a mechanism with a low processing overhead for randomly distributing events to the instruments. As it turned out, when events from a structure were being output very rapidly, the distribution between instruments often gave the illusion of a simultaneous or contrapuntal performance. The timbral differences between the instruments to a large extent contributes to this autonomy.

The function arrang randomly selects which instrument to output the event to. As the music testifies the selection does not simply flip-flop between instruments but can chose an instrument for up to five times in succession.

4.6 A Performance from the Algorithmic System

A Tale from Transitions was commissioned by the Public Broadcasting Association of Australia in 1986. In this work, the system demonstrated that the algorithmic technique had considerable advantages when using a microcomputer of limited power and resources. The processing overhead between structure performances is seldom noticeable, probably because it is difficult to detect. This can in part be attributed to the nature of the structures and their deployment during performance. During the performance, however, PERSSYS displayed state transitions at the console and in all likelihood, the console output took up a comparable time to that of processing a new state.

The composition has no defined beginning or end. For a performance to commence, one of the event structures must be selected and entered. This structure will not be performed, but simply primes the system for selection of the next structure. The data and structure selection mechanism can be found in appendix D.

The duration of the work is determined by a structure count which is entered into the system prior to performance. The number of structures accessed for a performance can range between 1 and 32,767. When the count has been reached the performance ends. With the tempo adjustment taking place at run time, it is difficult to estimate how long a selected number of structures will take to complete. By testing the duration of 10 or 20 structures a ball park figure can be arrived at which will approximate the actual duration of the performance.

A Tale from Transitions was one of five recorded performances from the system using the same set of event structures known collectively as The Life States. Performances ranged from 13 to 30 minutes. The longest performance was generated from 300 states. Each performance used the same material and although they have differing musical characters (structure order and interpretation) the data gave them a generic identity which is clearly recognisable.

Title Page | Acknowledgements | Abstract | Contents | Examples
Introduction | Chapter 1 | Chapter 2 | Chapter 3 | Chapter 5 | Conclusion
Bibliography | Discography | Appendices