# CASCADES: Interactive Algorithmic Performance

Skip other details (including permanent urls, DOI, citation information)This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 3.0 License. Please contact mpub-help@umich.edu to use this work in a way not covered by the license. :

For more information, read Michigan Publishing's access and usage policy.

Page 401 ï~~Cascades: Interactive AlQori thmic Performance G.W.Logemann, PhD Intel l igistics, Inc. Six Quarry Road Simsbury, Connecticut CT 06070 USA A computer with synthesizers becomes a performance instrument when equipped with controllers accepting input from one or more musicians. One such algorithm is described. A performance is organized by a script indicating the interpretation of gestures. Controllers can be discrete, such as terminal keyboard or MIDI instruments, or continuous, such as the Polhemus 3Space(R) Isotrak(R). Various classes of gestures are considered. Cascades are a series of programs exploring interpretive performance of an algorithm. They seek a point between those compositions which are completely predetermined and those which are exclusively improvised. MIDI sequences (the thematic material) generated by the Cascades algori thm (detai led in Logemann 1991) are trajectories of notes, where pitch, duration, articulation, and loudness are solutions to a general ization of the difference equations of acceleration. One or more trajectories can be generated concurrently in a cluster; one or more clusters can be generated concurrently or sequentially in a cascade. Initial conditions, extrema, and other variations (e.g., the number of trajectories in a cluster, the number of clusters in a cascade, the rule for de termi n i ng the end of a trajectory, the stereo effect, various degrees of randomization, and so on) are directed by the values in a parameter set; during rehearsal, the performer(s) create(s) a score or script, a list of parameter sets to be invoked sequentially in real time. Values in the parameter set, as well as the invocation of events thus determined, can be (I) entered from the computer keyboard; (II) computed from data from one or more MIDI instruments; or (III) computed from gestures with the Polhemus 3-Space (R) Isotrak (R), a device communicating three spatial dimensions and three angles of orientation. It is hoped that via the discipline thus imposed () the simple rule base imparts artistic unity; (2) the script of parameter sets encourages non-improvisatory creativity; (3) the real time interaction creates a virtual instrument, capable of artistic expression. ICMC 401

Page 402 ï~~The script file of Cascades II and III also identifies the mode, the algorithm to be used in interpreting input gestures, as well as parameters needed by the mode. Previously (Logemann 1989) we reported experiments using the Polhemus 3Space (R) Isotrak (R); herewith we outline a number of modes that might be used. Broadly speaking, there are two sorts of data needed by the algorithm: (A) invocation and termination of one or more processes (cascades, clusters, and/or trajectories); and (B) initial positions, velocities, accelerations, etc., used throughout the processes. In general, a controller generates values X={x(j), j=1,...,n), at time t. (E.g., for a one-button mouse or joystick, n=3; for the Polhemus device, n=6.) The range of the x(j) is generally an interval of integers, which can be 0 and 1 for switches; a set, e.g., 0 to 127 for MIDI pitch and loudness; or almost continuous, e.g., the output of the Polhemus device (16-bit integers) or an A/D converter. For theoretical simpl i city we can consider the discrete cases as embedded into the continuous, but for computational efficiency might wish to use integer or other discrete calculations. Direct values: Type B data can be taken directly from the x(j) or simple, e.g. linear or quadratic, transformations thereof. Derivatives: By keeping X and t from the previous point one can generate second or higher order differences; when scaled by change in t, such differences approximate veloci ties, accelerations, etc., that can be used directly or transformed into type B data. Speed can be the RMS magnitude of the velocity vector, or more simply the sum of the absolute values of the velocity components. Thresholds: By defining planes or more general quadratic surfaces we can create thresholds which when crossed trigger type A data. Direct values, derivatives, or transformations thereof can be used in the calculations. For now, it is significantly faster computationally to create routines calculating any particular set of thresholds (e.g. planes parallel to the x-y axis by defining a set of z values) than to al low the most general surfaces, determined by quadratic forms which in simple cases have mostly zero coefficients. Series: Some type A triggers may be calculated from a series of events. For example, a downbeat gesture can be recognized as (1) a threshold enabl ing looking for the downbeat, e.g. speed below a certain value; (2) a pair of ICMC 402

Page 403 ï~~thresholds indicating sufficient speed has been achieved in the -z direction; (3) a threshold indicating speed has reduced to almost zero. Patterns: By keeping a set of points Ct(i),X(i), i=1,...,r}, one can calculate further entities. For example, the coefficients from least-square polynomials might be used as continuous data in the above schemes. However, with smooth data simpler schemes apply, such as picking a few widely separated points. E.g., three points determine a parabola, from which the constants can be calculated to determine the solution to a second order difference equation. Alternatively, matches to canonical patterns can yield type A data. In general, recording the pattern might conveniently be done in a series, with type A events indicating starting and stopping. Directions: The direction of the velocity vector (possibly scaled by speed) is a useful special case of pattern to be compared with one or more canonical vectors, e.g., to distinguish between strokes up, down, left, and right. Recognizing that some of the concepts introduced above might find wider application, a logical next step would be to develop a language expressing the interpretation of spatial gestures. Some of the simpler calculations can quickly be described using systems such as Opcode's Max. Most have been implemented in C using multitasking admitted by MoxC (Dannenberg 1986). References Dannenberg, R.B. 1986. The CMU MIDI Toolki t. Carnegie Mellon University (Pittsburgh PA 15213). Logemann, G.W. 1989. "Experiments with a Gestural Controller". In T. Wells and D. Butler, eds., ProceedinQs of the 1989 International Computer Music Conference, pp. 184-185. Logemann, G.W. 1991. "Cascades: Algorithmic Gestural Performance". Journal SEAMUS VI(1):10-15. Pluckette, M. and D. Zicarell i. 1991. Max. Opcode Systems, Inc. (Menlo Park CA 94025-1010). ICMC 403