Overview
Keywords
- Algorithmic Composition
- Automatic Composition
- Computer-aided Composition
- Sound file generation
- MIDI file generation
- Score generation
- Common Lisp
- Common Lisp Object System (CLOS)
- Common Lisp Music
- Common Music
- Common Music Notation
- Lilypond
- Algorithms:
- Fibonacci Transitions
- Lindenmayer Systems
- Rhythm Chains
- Set Manipulation
- Permutations
- Popcorn
- Intra-Phrasal Loop Chopping
Description
slippery chicken is a specialised algorithmic composition program written in the general programming language Common Lisp and its object-oriented extension, the Common Lisp Object System (CLOS). Work on slippery chicken has been ongoing since 2000. Specialised as opposed to generalised means that the software was originally tailor-made to encapsulate my personal composition techniques and to suit my own compositional needs and goals. As the software has developed however, many general-purpose algorithmic composition tools have been programmed and these should be useful to a range of composers. The system does not produce music of any particular aesthetic strain—for example, although not programmed to generate tonal music the system is quite capable of producing it. But if it is to be used to generate complete pieces it does prescribe a certain approach, as described below.
The algorithmic system in slippery chicken is mainly deterministic but can include stochastic elements. It has been used to create musical structure for pieces since its inception and is now at the stage where it can generate, in one pass, complete musical scores for traditional instruments, or with the same data write sound files using samples, or MIDI file realisations of the instrumental score. The project's main aim was, and to an extent still is, to facilitate a melding of electronic and instrumental sound worlds, not just at the sonic but at the structural level. Hence certain processes common in one medium (for instance audio slicing and looping) are transferred to another (the slicing up of notated musical phrases and the instigation of sub-phrase loops, for example). Techniques for innovative combination of rhythmic and pitch data—in my opinion one of the most diffcult aspects of making convincing musical algorithms—are also offered.
The system includes but is not mainly concerned with the automation of some of the more laborious aspects of instrumental composition—transposition, harmonic and rhythmic manipulation for example—and thus facilitates and encourages more experimentation than is generally possible when the composer has to perform these tasks with the traditional pencil and paper. By generating music data algorithmically, independent of output format, structures are available for use in the preparation of digital and notated music (in the digital case particularly for the generation of parameters for the digital synthesis and signal processing language CLM). The programme in nascent form was first used for the generation of the tape part of a piece for instruments and tape (slippery when wet). Its success in sonically and structurally integrating the instrumental and digital structures in that piece provided the impetus to pursue the idea further in the area of instrumental composition.
What slippery chicken is focused upon then, is using the pre-existing software tools in CM, CLM, and CMN, along with the rich data structure management of Lisp and CLOS, to achieve a top-down approach to musical composition: defining, ordering, combining, and manipulating rhythmic, pitch, and dynamic information into complete or "ready-for-fine-edits" pieces of music. The output of the program is in the form of MIDI sequences (generated by CM's MIDI interface and containing all the tempo and meter information that facilitates reading into notation software such as Sibelius), postscript score files (generated by interfacing with CMN, and thus allowing the algorithmic use of arbitrary symbols, note heads etc.), LilyPond files (with similar advantages to CMN), and sound files (using samples driven by a custom, multi-channel CLM instrument).
The approach to algorithmic composition here is sequence or phrase-based (though this should not be confused with MIDI sequencing). We define a certain number (a palette, in slippery chicken terms) of rhythmic phrases, a palette of chords (sets), and then map these onto instruments through rhythm and set map objects which, when combined, select notes to form a complete piece.
One of the most difficult aspects of algorithmic composition for instruments—at least in pieces where there should be a semblance of phrases formed of connected notes—is, in my opinion, the satisfactory combination of rhythms with pitches. For instance, if we were to place a rhythmic phrase without pitch information in front of a trained composer, s/he could no doubt sing or play back a number of pitch sequences that would "work" with these rhythms (the implication being that not all pitch sequences would work with the given rhythms; that the pitches selected would very clearly be influenced by the given rhythms). The same is true if the composer were offered a sequence of pitches without rhythms: the selected rhythms would be dependent on the given pitches. The process of matching one to the other is complex and individual, dependent on culture, musical experience, taste, etc. Thus formalision of this process is difficult.
My solution here is to provide an arbitrary number of "pitch curves" (perhaps algorithmically) to each rhythmic sequence. These curves consist of a list of simple integers, one for each rhythm, over an arbitrary range but where, for example, 2 would indicate a higher pitch than 1. When we have mapped our phrases to our instruments and our sets to our phrases, it is then a matter of selecting pitches from the set and the current pitch curve. We can define a hierarchy to specify which instrument gets the pick of the notes first: an attempt will be made to use as many notes of the set as possible, spreading them out between the instruments in the ensemble. Simple in concept at least then, the basic procedure for using slippery chicken—any part of which may be algorithmically or manually specified—consists of defining:
- the instruments: ranges; transposition; chord selection function (if applicable); microtonal potential; any notes (especially microtones) that the instrument can't play etc.;
- the instrument changes for individual players (e.g. flute to piccolo);
- the set (harmonic) palette that the piece will use;
- the rhythm sequence palette;
- the rhythm sequence map: sequences onto instruments;
- the set map: sets onto sequence progressions;
- the tempo maps/changes;
- the set limits: for the whole piece and/or instruments (these are curves that form restrictions on the lowest and highest notes selectable from any given set; they are used to control global instrumental and ensemble pitch height/width development).
scei
The engagement with slippery chicken has become a self-sufficient project, one which has, apart from the main instrument-with-computer works, generated a collection of self-sufficient little pieces in the form of sound files. They are all called scei (= slippery chicken egg, where Ei is German for egg...).
Contrary to traditional studio work (which can often be thought of as sound sculpting) my approach here is to generate perhaps hundreds of sound files automatically from a given sample palette and set of compositional data. Sound file selection then, as opposed to sound crafting/design, becomes the main activity before mixing.
The best results of the algorithms (with no post-output editing) are to be found on the sumtone site as short but complete pieces.
About the title
The structural ideas for slippery chicken were developed during the composition of two pieces of mine, the techniques of which led to their formalisation in this programme: pas de poule,pas de pot and slippery when wet, hence the combination of the two titles into something even more abstruse and silly than the originals (humour is an important part of staying sane whilst programming). Also, the overall design of the software was quite taxing and some organisational problems were about as easy to grasp as a slippery chicken (plucked, naturally).
Documentation
Up-to-date documentation of slippery chicken methods, functions, and classes is constantly in development. The user manual is available here. In addition, the diagram of the class hierarchy may be of interest.