69Scaletti

Carla ScalettiSymbolic Sound CorporationP.O. Box 2549Champaign, Illinois 61825–2549 USAscaletti@symbolicsound.comwww.symbolicsound.com

Computer MusicLanguages, Kyma,and the Future

Computer Music Journal, 26:4, pp. 69–82, Winter 2002Ó 2002 Massachusetts Institute of Technology.

Eric Lyon organized this symposium around thefollowing two questions. Why has some computermusic software survived and developed a follow-ing? Where is computer music software today, andwhere might it be headed in the future? Acknowl-edging that the term ’’computer music’’ is by nowredundant, since virtually all music involves theuse of computers in some form or another, heposed these questions with respect to computermusic software that supports experimental music.Experimental music is not limited to any speci� cmusical style or genre. An experimental musicianis one who approaches each act of musical creationin a spirit of exploration and innovation, often withthe goal of inventing new kinds of music that havenever been heard before.

I would like to take Eric Lyon’s re� nement a stepfurther by observing that all of the software exam-ples included in this symposium (along with someothers that are not represented here) belong to aspecial category of computer music software calledcomputer music languages. Most software packagescan be classi� ed as utilities; they perform a well-de� ned, familiar function that is needed by a largenumber of people. A software package that emu-lates all the functions of the traditional multi-trackrecording studio would be one example of a utility.But the pieces of software that Eric Lyon has cho-sen to include in this symposium are different;they are examples of computer music languages.

A language provides one with a � nite set of’’words’’ and a ’’grammar’’ for combining thesewords into phrases, sentences, and paragraphs toexpress an in� nite variety of ideas. A language doesnot do anything on its own; one uses a language toexpress one’s own thoughts and ideas. This is whatmakes these particular software packages so open,extensible, and useable in ways unanticipated bytheir authors. And that is why, although they maynever command the same market share as utilities,

they have had a longer-lasting and deeper in� uenceon the evolution of music.

This article is organized into three sections. The� rst section is an identi� cation and discussion offactors that can contribute to the success and lon-gevity of a computer music language. In the middlesection, I try to illustrate some of those factors(like extensibility) using speci� c examples from theKyma language. The last section is a speculation onthe role computer music languages could play in afuture world where art, the economy, and humanbeings are very different from the way they aretoday.

Factors Contributing to the Successof a Language

Why have some computer music languages sur-vived over the years and attracted a sizeable num-ber of users? Although we would like to believethat the only reasons for the success of these lan-guages are their inherent attributes, many of thefactors contributing to success have little to dowith the language or technology itself. There are,for example, the lucky accidents of geography,economic/social class, and chromosomal makeup.Given these ’’accidents’’ of birth and fortune, whatother necessary (but not suf� cient) factors can con-tribute to the longevity and acceptance of a com-puter music language?

Reasons Intrinsic to the Language

Several factors intrinsic to a language contribute toits relative success. A language is successful if peo-ple are using it successfully. It does not matter howelegant or beautiful a language is in theory or onpaper if no one is using it. Any language that haslongevity and a following also has a correspondinglist of creative projects that have been successfullycompleted using that language.

70 Computer Music Journal

A language is successful if it answers a need thatis not otherwise satis�ed. How does a languagegain users in the � rst place? First it must ade-quately address some basic needs, and then it mustalso answer some need (tangible or otherwise) thatis not currently being satis� ed elsewhere.

A language is successful if it is able to expressthe unanticipated. In a computer music language,just as in a natural language, it should be possibleto say something new. For example, a highly re-strictive data-� ow editor—while it may protect onefrom mistakes—also prevents one from discoveringthe sounds that its author could not imagine. Asuccessful music language does not impose a par-ticular musical style upon its users; it must be � ex-ible enough and abstract enough to generatemusical utterances in any style and in any genre.

A language is successful if its underlying datastructure can support extensions and multiple in-terpretations without violating the original model.This ability to express the unanticipated extendsbeyond the users of the language to the developersof the language. The underlying data structures of asuccessful language should make it easily extensi-ble, even in directions that the designer had notoriginally anticipated. When a language has thischaracteristic, it can evolve and adapt.

A language is successful if its author can strike abalance between providing users with what theysay they need and what they do not yet know thatthey need. It comes as no surprise that when theauthor of a computer music language is willing tomake adjustments and additions to the language inresponse to user feedback that those languages be-come more successful and develop a loyal follow-ing. But the feedback process is not quite as directas it might seem at � rst glance. If an author simplywent through the ’’wish lists,’’ item by item, add-ing each feature that was asked for, the resultwould be a bloated and jumbled mass of featureswithout the logic or framework necessary for theuser to make sense of it all.

Instead, the authors of the successful languageshave had to digest and analyze the feedback � rstbefore making modi� cations to the language. Theyhave had to combine all the speci� c requests, gen-eralize them, and produce meta-solutions that sat-

isfy several of the issues at once. Even moreimportant is the task of giving people what they donot yet know that they need. People do not alwaysknow that they want something if they have neverseen it before. But that is often exactly what theywant and need most of all: something new.

A successful software designer must maintain abalance between responding to user feedback andmaintaining a consistent vision for the language.At times, it is the users who are specifying the lan-guage and at others, it is the author who forgesahead into new territory. This is not so differentfrom a composer who gives the audience some fa-miliar material while also nudging them along intonew musical territories.

Reasons Extrinsic to the Language

A language is successful if one can learn it andlearn from it. Whereas the success of a utility de-pends in large part on its being completely obviousand easy to use without having to refer to the man-ual, computer music languages, by de� nition, re-quire more of their users. Simply knowing thesyntax of a language does not automatically giveone something interesting to say. The most suc-cessful users of computer music languages arethose who also take an interest in learning moreabout sound, music, and structure. For a computermusic language to be successful, there must also beopportunities for learning more about sound andmusic creation in the context of that language:workshops, courses, tutorials, extensive documen-tation (via print and other media), books, lectures,an online forum, technical support, etc.

One of the bene�cial side effects to learning acomputer music language is that the basic princi-ples are completely transferable to other languagesand even to other utilities and hardware setups.Learning a computer music language provides onewith a basic understanding of sound, logic, andstructure that one can apply no matter how tech-nology evolves in the future. By contrast, theknowledge of which buttons to press in a special-purpose utility becomes obsolete as soon as thatutility is upgraded or replaced.

71Scaletti

A language is successful when it has a commu-nity of users. Although an artist is almost by de� -nition independent, there is also some stimulationand practical assistance to be derived from interact-ing with other people who use the same language.Successful languages have groups of users who pro-vide technical support, new developments, educa-tion, and appreciation for each other.

A language is successful when it serves as anexus for interdisciplinary cross-fertilization. Themost powerful function of any language (whether itis a programming language, a computer music lan-guage, or a natural language) is to act as a nexus forthe cross-pollination of ideas among different� elds. Each person who uses a language also hassome effect on its development. When a language isgeneral enough to satisfy the needs of users havingdifferent backgrounds, different goals, and differentknowledge sets, it can also act as the vector fortransferring ideas and protocols from one disciplineinto another. When the ideas and protocols are ap-plied in the new � eld, they acquire additions andalterations that in turn � nd their way back into thelanguage, and so on.

A language is successful when its author uses itregularly. Using one’s own software gives one a dif-ferent perspective than is possible from merelywriting it. There is no better way to fully identifywith the users of the software and get ideas for im-provements than to compose with the language,perform on stage with it, and otherwise use it inthe same way its users do. The more the authorcan do this, the better the language becomes.

A language is successful when the people behindit are committed to its success. In the end, the sin-gle most important factor in the success of a lan-guage is that its author, its users, a company, and/or an institution are committed to its continuedexistence. Behind every successful language, onecan � nd an individual or individuals dedicated tothe perpetuation and further development of thatlanguage. Some very interesting and beautiful lan-guages have had to be abandoned by authors whofelt compelled (economically, professionally, orsimply due to their own breadth of interests) topursue other projects.

A language cannot be successful unless it �rstexists. Although this may seem obvious, the � rst

step towards creating a successful language is tostart writing music software in the � rst place. Cre-ative environments where many people are writingsoftware can remove the barrier of ’’over-reverence’’ that sometimes surrounds existing lan-guages (which may appear as if they had sprungfully formed out of nothing and to have existed for-ever). A healthy environment for language develop-ment is one in which there is a lot of softwareexperimentation and where the conversation is justas likely to turn to software architecture as it is tothe weather or the news.

A language is successful when people are readyfor it. In technology, it seems that if an idea arriveseven a little bit too early, it has to struggle for sur-vival, but once the time is right, there is an explo-sion of development and growth. People have to beconceptually prepared to receive and understandwhat is presented to them, and the essential tech-nological infrastructure must be in place in order toreach potential users and achieve the basic func-tionality.

A language is successful when people say that itis successful. If you live in a village where every-one believes in witchcraft and the local witch putsa public hex on you, it won’t matter that you are acheerful person in the best of health; everyone willstart treating you as if you were already dead. Whatis said becomes the truth. And when something isin print, it carries even more authority. So havingsome good things said about the language in themedia, on the web, in journals, and in the historybooks lends the language an air of credibility andpermanence.

A language is sometimes successful due in partto pure luck. The successful languages are the oneswhose designers were prepared to recognize andtake advantage of being in the right place at theright time.

A language is successful if it has contributedideas and stimulated new developments in the�eld. Even the most successful of languages willnot stay around forever, but the ideas from thoselanguages will endure and in� uence the directionof future developments. Human beings build lan-guages (natural languages, computer languages, andmusic) as a collective project, often with the same

72 Computer Music Journal

blind dedication displayed by termites building anest. Each individual works, almost by instinct, onsome small portion of the project without beingable to fully conceive of the part it plays in thelarger structure. The higher-level structure (in thiscase ’’human knowledge’’ or ’’culture’’) is an emer-gent property of the myriad of smaller structuresbuilt by individuals.

The Kyma Language

Origins

Where did Kyma come from? Kyma comes in partfrom a fusion of my childhood interests in bothmusic and science and from pencil-and-paper at-tempts to algorithmically map patterns in nature topatterns in music written for acoustic instruments.In part it arose out of the atmosphere at the Uni-versity of Illinois in the early 1980s, an environ-ment rich in living examples of composers andengineers who were creating their own computermusic languages and instruments or extending ex-isting languages to suit their compositional require-ments. (Consider, for example, Herbert Brun’selegant and algebraic SAWDUST language, Salva-tore Martirano’s SalMar language/instrument forreal-time composition, John Melby’s extensivescore manipulation subroutines, Jim Beauchamp’svoltage-controlled analog synthesizer and his laterforays into hybrid synthesizers and computer mu-sic languages, Sever Tipei’s MP1 algorithmic com-position language, and the CERL Sound Group’slong line of digital synthesizers and music softwareculminating in the Platypus user-microcodableDSP designed by Lippold Haken and Kurt Hebel in1983.) In part it arose out of my fascination withtape music—with being able to literally hold bits ofsound in my hands and to manipulate time by rear-ranging the pieces and taping them back togetherlike a � lmmaker. And in part it arose out of myfrustration with computer music languages of thetime, which felt almost like a step backward fromtape music, because they were de� ned in terms ofmusic notation played on ’’instruments’’ and could

provide no real-time interaction. To my mind,though, these shortcomings were overshadowed bythe promise of the structural, organizational, andalgorithmic power of the computer, so Kyma wasalso inspired by these earlier computer music lan-guages.

Kyma also drew inspiration from a languagecalled Smalltalk and the paradigm of object-oriented programming. To me, ’’object’’ suggestedsomething like the snippet of audiotape that Icould hold in my hands. But it also suggested amore abstract conceptual grouping of atomic orcompound sound objects that could be manipulatedor viewed as a single entity and then ’’zoomed’’ toreveal arbitrary levels of detail. Kyma was also in-� uenced by the courses I took on data structures,mathematical logic, automata theory, discretemathematics, and graph theory at the University ofIllinois. In a 1986 course on Programming Lan-guage Principles, I wrote a term paper called’’KYMA: A Computer Language for the Representa-tion of Music’’ describing an object-oriented pro-gramming language for analog circuit simulation,score representation, rule-based composition, anddirect manipulation of waveforms.

I started writing code for the � rst version ofKyma in Apple Smalltalk running on an AppleMacintosh 512K in 1986. In 1987, I modi� ed Kymato make use of the Platypus signal processor as anaccelerator and demonstrated it at the 1987 Inter-national Computer Music Conference in Cham-paign (Scaletti 1987). In 1989, Kurt Hebel and I hadconcluded that it was not in keeping with the man-date of a university research laboratory to build,distribute, and support hardware and software. Sowe formed a company, running it for the � rst threeyears from our third-� oor student apartment. Weassembled hardware in the kitchen, developed soft-ware in the spare bedroom, used a closet stuffedwith sound-absorbing blankets as our recording stu-dio, and used the living room for faxing, mailing,packing, and shipping. That � rst summer, we couldnot afford to run the apartment’s air conditioner,but we continued programming and hardware-designing into the fall and winter, � nally hearingthe � rst sounds from the Capybara at midnight onNew Years’s Eve (in the � rst few minutes of 1990).Thanks to the extraordinary vision of our � rst cus-

73Scaletti

tomers, who understood what we were doing longbefore anyone else took us seriously, we managedto bootstrap Symbolic Sound Corporation andmove into our � rst real of� ce in 1992.

Since that � rst version of Kyma in 1986, therehave been � ve major software revisions, a portfrom the MacOS to Windows in 1992, and ports to� ve different hardware accelerators. The user basehas expanded from a single composer/software de-veloper working in a university research lab to aninternational community of musicians, sound de-signers, and researchers. Symbolic Sound has been,for us, an alternative means to the end of continu-ing our research and teaching. Our research andideas are embodied in software, hardware, andsound, and we have been privileged to teach (andlearn from) heterogeneous groups of individuals ofevery age and background, many of whom havealso become our colleagues and friends.

In presenting this concise personal history, Ihope to highlight the fact that no computer lan-guage ever springs fully formed out of nothing.Each language has a distinctive � avor to it im-parted by the primordial ’’soup’’ in which it wasspawned—a history, a personality, and a reason forbeing. Each language is the complex embodimentof a theory of sound, music making, and structure.The basic assumptions of each language show theimprint of the designer’s personality, experiences,theories, and training.

De�nition and Rami�cations of the Sound Object

Kyma is a language for specifying, manipulatingand combining sounds (Scaletti 1997), and it isbased on the following de� nition:

A Sound is de� ned to be a Sound S, a unaryfunction of another Sound f(S), or an n-ary func-tion of two or more Sounds f(s1, s2, . . ., sn).

For example, a Sound might be a source of sound(like the audio input, a sample, or a noise genera-tor). It could be a unary function of another Sound(like a LowPassFilter of another Sound). It couldalso be an n-ary combination of several Sounds(like a Mixer with twelve input Sounds).

The de� nition is recursive, so one can build arbi-trarily long chains of functions of other functions(for example a LowPassFilter of a HighPassFilter ofa Mixer of three mixers and the microphone input).Some of the functions are temporal functionscalled TimeOffsets and SetDurations. Using thesetemporal functions within a structure, one can cre-ate sequences of Sounds, mixes of overlappingSounds, and other time-varying structures.

One of the rami� cations of this abstract, recur-sive de� nition is that Kyma makes no distinctionbetween ’’samples,’’ ’’live audio input,’’ and syn-thetically generated signals. They are all Soundsthat act as sources, and they can be manipulatedand composed using the same sets of unary andn-ary functions. Another rami� cation of the Soundobject de� nition is that Kyma does not draw adistinction between ’’instrument’’ and ’’score.’’Instead, it provides an abstract way to build hierar-chical structures that might or might not corre-spond to traditional musical organization.

This recursive de� nition forms the basis ofKyma. Kyma would still be Kyma even if it had nographical user interface and no hardware accelera-tor (and in fact the � rst version of Kyma was com-pletely text-based and ran on a single processor).

Multiple Viewpoints on the Same AbstractData Structure

Rather than calling Kyma a ’’graphical language,’’it would be more accurate to call it a language thatprovides multiple ways of viewing and manipulat-ing data. The current graphical representation ofKyma Sounds has evolved over several years as Ihave tried to discover the most direct and appropri-ate representation for understanding and manipu-lating the Sound structures. The abstract structurecame � rst, and the graphics evolved (and continueto evolve) in order to elucidate the structure.

Evolution of the Graphic Sound Editor

Initially, a Sound was speci� ed symbolically asSmalltalk code. This quickly evolved into a kind of’’selection-from-lists’’ interface (shown in Figure 1)

74 Computer Music Journal

in which one could select a class and its creationmethod from lists, and they would then be auto-matically typed into a window. Previously createdSounds appeared in lists on either side of the codewindow, so they could be used as arguments tonew Sounds. Its indentation level represented theposition of a Sound in the hierarchical structure,and one could select any level and listen to it atthat point.

In an attempt to further reduce the need for typ-ing, I changed the interface to the ’’Russian doll’’style interface shown in Figure 2, where Sounds arerepresented as ’’containers’’ of other Sounds.Double-clicking on a Sound opened a windowshowing the Sound’s input(s) and parameter values,double clicking on those inputs revealed their in-puts, and so on.

This succeeded in revealing the recursive natureof the structure but was not very good at showingthe overall structure and the connections betweenthe Sounds. Finally, I realized something that had

been right at my � ngertips (literally) all along.Every time I tried to describe the structure of aKyma Sound, I always drew a picture like the onein Figure 3.

All this time, I had been describing Sounds inone way but representing them on the computerscreen in a different way. It � nally occurred to methat a drawing of the Sound structure could bemore than just a tool for describing and under-standing the Sounds: it might also be the most di-rect way for people to create and manipulate theSounds. In other words, the same representationcould be used for both analysis (i.e., a descriptionafter the fact) and synthesis (i.e., creating and modi-fying the structures). For me, at least, this was animportant conceptual breakthrough. It was the � rsttime I realized that synthesis is just one speci� ccase of analysis.

I changed the graphical representation of Soundsfrom boxes-within-boxes to something that lookedlike the screen shot in Figure 4, a graphical repre-

Figure 1. Kyma screenshotfrom 1987. After selectinga Sound class from the listin the upper left and acreation method from thelist at the upper right, thecreation code would be

automatically pasted intothe center pane. The hier-archical structure of theSound was represented us-ing indentation levels(lower right), and the cur-rently selected subSound

was displayed in the lowerleft pane. The panes to theleft and right of the centerpane are lists of previouslycreated Sounds that couldbe used as inputs to theSound in the center pane.

75Scaletti

sentation of the functions, clearly in� uenced bythe representation of trees and Directed AcyclicGraphs (DAGs) in computer science. The defaultsignal � ow direction was from bottom to top (anin� uence of the textbook illustrations of Music Nunit generators).

The direction of signal � ow was user-selectable,so one could reverse the signal � ow direction orrotate it 90 degrees. In� uenced by DSP textbooksand papers, I eventually decided to standardizethe Sound representation to one showing the sig-nal � owing from left to right (as shown later inFigure 6).

Note that through all of these changes in graphi-cal representation, nothing about the underlyingSound structure changed. However, even some-thing as simple as changing the direction of signal

Figure 2. HierarchicalSound structure repre-sented as boxes withinboxes (Scaletti andJohnson 1988).

Figure 3. Drawing of aKyma Sound structure(Scaletti 1989).

76 Computer Music Journal

� ow had a noticeable effect on the way people un-derstood and manipulated that underlying structure.

Evolution of the Graphical Timeline

Kyma’s Timeline editor is yet another view of thatsame underlying data structure. Kyma Sounds havealways been able to represent time-varying signal� ow architectures through the use of the Time-Offset and SetDuration modules. These representchanges to the structure of the signal � ow itself,not ’’events’’ in the sense of parameter updates. Inoticed that whenever I wanted to explain the ef-fects of the TimeOffset and SetDuration in a Sound(see Figure 5a), I would illustrate it using bars andvertical time markers (see Figure 5b).

Similarly, whenever I wanted to create a time-varying synthesis architecture, I would always startby sketching it out as a timeline on paper � rst. Itwas another case of � nally realizing that the bestrepresentation for specifying and manipulating astructure was the one that I, along with everyoneelse, had already been using on paper.

I also noticed that whenever I wanted to create aparameter control function, I would � rst draw thedesired control function on paper and then workout the arithmetic combination of functions togenerate that shape. That is why the Kyma.5 time-line (shown in Figure 6) allows one to draw thecontrol functions.

The Timeline was not so much a change toKyma as it was the addition of an alternate view onthe original underlying Sound structure. (And, judg-ing from the number of complex, multi-layeredsounds and performances that have been createdusing the Timeline, it must have been a closermatch to the way people conceive of time varyingstructures).

Evaluating the Appropriatenessof a Representation

At the risk of belaboring the point, all of these ex-amples illustrate that there can be multiple ways ofviewing and manipulating a single abstract struc-ture. Each alternative can reveal or emphasize dif-

Figure 4. Early GUIversion of the Kyma Soundstructure (Scaletti andHebel 1991).

77Scaletti

ferent aspects of the structure and in� uence thekinds of things people choose to create using thatstructure.

Sometimes symbols are the clearest and mostdirect representation, and sometimes a graphicalrepresentation can be clearer and more compact.Kyma provides both graphical and symbolic inter-face elements, depending on the context. Arrivingat the most appropriate representation nearly al-ways requires some experimentation and a few in-spired realizations. In the Kyma language, thatevolution is still in progress and is part of the funof participating in a living language.

Extending the Data Structure

Sound objects have also proven to be extensible inways I had not originally anticipated. In the � rstversion of Kyma, for example, although the struc-tures could be time-varying, the parameter valueswere all constants. As we and other users workedwith the language, we came to realize that by mak-ing the parameters event-driven, we would notonly be making the language more interactive, wewould also be opening it up to external control

from event sources like MIDI controllers andMIDI-generating software. So in Kyma version 4.5,we added an event language, including internal andexternal sources of asynchronous events and real-time expression evaluation, on the Capybara. Theimprovement in the quality of the sounds peoplemade in the new version demonstrated the powerof event-driven live interaction. And we werepleasantly surprised that the original data structurehad been robust enough to accommodate this kindof major shift.

Expanding the Algorithm Set

One of the ideas behind the Kyma framework (andindeed behind any ’’modular’’ software or hard-ware) is that one can easily plug new sound synthe-sis and processing algorithms into the existingstructure and immediately use them in conjunctionwith existing ones. Kyma has proven itself openenough to accommodate several new synthesis andprocessing algorithms that we have developed overthe years. The most recent example is the additionin 2001 of a new family of synthesis and processingalgorithms called Aggregate Synthesis.

Aggregate Synthesis is an extension to the classic’’additive synthesis’’ algorithm in which complextimbres are created by adding together the outputsof hundreds of sine wave oscillators. AggregateSynthesis extends this idea by using elements otherthan oscillators as the basic generators. Besides theclassic ’’oscillator bank,’’ one can also use a bankof band-pass � lters, a bank of impulse responsegenerators, or a bank of grain cloud generators.These alternative generator banks are controlled bythe same analysis � le (or live spectral analysis) asthe classic oscillator bank, so Aggregate Synthesis

Figure 5a. Using Time-Offsets (D1 and D2) to cre-ate a time varying Soundstructure (Scaletti 1992).

Figure 5b. Describing theresults of a time-varyingSound structure on paper(Scaletti 1992).

78 Computer Music Journal

can be used for live analysis/resynthesis with addi-tional control parameters like grain duration, grainenvelope, grain waveform, etc.

The Role of the Capybara

Every computer music language uses hardware (be-cause every computer music language runs on acomputer). In its current implementation, Kymaruns in a distributed manner on two general-purpose computers: a Macintosh or PC and theCapybara. The Capybara is a general-purpose mul-

tiprocessor computer designed by Kurt Hebel tohave a scalable architecture that, in its current in-carnation, can support from 4 to as many as 28 par-allel processors (with 4 or 8 analog and digital24-bit 100 kHz audio inputs and outputs). It is notspecial-purpose hardware: it is not a collection ofoscillator and � lter circuits hardwired into a cen-tral mixer. Its function is completely determinedby software. In our ’’vision-centric’’ society, peopleroutinely dedicate hardware towards the accelera-tion and improved quality of real-time video andgraphics. Audio artists deserve the same considera-tion (and dedicated computing cycles!).

Figure 6. Screenshot ofKyma.5 user interface(Scaletti 2000).

79Scaletti

Language as Nexus

Kyma serves as a nexus connecting sound design-ers, musicians, artists, programmers, and research-ers who work in different geographical locationsand who bring with them different sets of goals anddifferent ways of thinking about sound andproblem-solving. They use Kyma to create soundsfor feature � lms, advertisements, and computergames; they are using Kyma on albums, in stageshows, for live theatre, in installations, in clubs, inclassrooms, at parties, in laboratories, in ware-houses, and at home.

I learn a great deal by talking with Kyma users,and, by inference, from watching them work,studying the sounds they create, and analyzing thequestions they ask or new features they request.That knowledge becomes incorporated into Kymaand subsequently transferred, via Kyma, to all theother Kyma users who then further transform thatknowledge according to their own approaches andways of thinking about sound. Thus, Kyma is serv-ing as a conduit for information and knowledgetransfer between disciplines, resulting in some ex-citing cross-pollinated hybrid art forms and new ap-proaches to processing and synthesizing sound.

Future Directions for Computer Music Software

What form will computer music languages take ina future world populated by prosthetically and ge-netically enhanced humans having a broader con-cept of art and an economy based more on servicesthan on physical objects?

I foresee computer music languages that are per-fectly scaleable, modular, dynamic networks of dis-tributed computational elements. They will becustomized aggregations of independent computa-tional elements (some of which will be virally de-livered directly into our brains) that can operate inisolation or in cooperation with additional ele-ments accessed, only as needed, via the Internet.

I see computer music languages evolving towardmore general ’’virtual space’’ languages in which asingle database or model world drives the genera-

tion of sound, visuals, tactile feedback, physicalmotion, and direct neural stimulation. In these lan-guages, it will become even clearer that the map-ping is the message: given identical model worlds,the art lies in selecting or directing the observer’spath through that world and in mapping the num-bers into perceptual stimuli (or electrical signalssuitable for directly stimulating neurons).

On the hardware side, I see an ever more urgentneed for multiple, broad-band interfaces—widechannels for pumping data into and out of the vir-tual spaces to create a fully ’’immersive’’ experi-ence.

New Humans

Hybrid Vigor

Populations are shifting and, in accordance withthe principle of ’’hybrid vigor,’’ all this stirring upof nationalities and cultures and genes is resultingin stronger, smarter, and healthier human beings.Future computer music languages written by thesefuture humans will embody new ways of thinkingabout time, space, quantity, physical movement,music, and sound.

Self-Modi� cation

We are living through the early part of a centurywhen life will rede� ne itself through genetic engi-neering and implant technology. There is no ques-tion that the agricultural and industrial revolutionshad a big impact on human development, but thegenetic revolution is more than that. It is a rede� -nition of what it means to be human, of what itmeans to be alive. We are witnesses to the momentwhen the DNA molecule is just � guring out how itcan modify itself.

Body modi� cations that are now practiced as amatter of style are just rehearsals for future self-modi� cations that will include intelligent implantscontrolled by the same neural circuits as ’’natural’’biological parts. The distinctions we now draw be-tween ourselves and our machines will be blurredand ultimately erased.

80 Computer Music Journal

New Art

Traditional distinctions between music, � lm, ani-mation, and games will also become blurred. Art ofthe future will consist of a multi-dimensional space(literal or abstract) and a set of (deterministic ornon-deterministic) ’’paths’’ through that space.This model is equally serviceable in describing apiece of tape music, a computer-generated anima-tion, a live-action � lm, a theme-park ride, a liveimprovisation with computer partners, a painting, anovel, a computer game, a traditional piano sonata,a virtual environment, a live DJ mix, or an installa-tion. ’’Audiences’’ of the future will consider all ofthese experiences to be art works and will � nd theold distinctions as foreign as the idea of sitting qui-etly in their seats during a performance.

The Space

The space of an artwork can be anything from aphysical, three-dimensional space (where thedimensions would be time-stamped x, y, and zcoordinates) to a completely abstract higher-dimensional space (where the dimensions might bethe allowed pitch classes or timbral characteris-tics).

The Paths

A path through the space can be a predeterminedor recorded path chosen by the artist (as in anacousmatic tape piece, a � lm, or a theme-park ridewhere the participants sit in cars pulled alongtracks). Alternatively, it can be a ’’live’’ path (orpaths) where the ’’audience’’ and/or improvisingperformers explore the space interactively.

New Economics

Software and music have much in common: bothare complex abstract structures manifested asephemeral modulations of an invisible medium.And unlike many commodities, one cannot buymusic or software; one can license it for personaluse, but the ownership remains with the author.

Under the old model, a musician or programmerwas expected to produce a physical object (a com-pact disc) that could be distributed via trucks andairplanes to local storage centers (stores) whereconsumers could purchase them. Because consum-ers exchanged cash for the physical object andowned the storage medium, they were led to be-lieve that they also owned the music or softwareand could therefore freely give it away or reuse anyportion of it. Improvements in digital recordingquality and network speeds have begun to make itmore obvious that software and music are notphysical objects that can be purchased and owned.Music creation, like software creation, is a pro-cess—an evolutionary, ongoing, iterative project.As such, it is ill-suited to the object distributionmodel that worked so well for refrigerators and ba-nanas, for example, in the last century.

Renting the World

What if the market for music and software werebased on subscriptions rather than on one-timepurchases? For example, one would subscribe to asoftware provider, a favorite composer or author, orto a consortium of like-minded artists orprogrammers. In exchange for a yearly subscriptionfee, one would receive unlimited access to the lat-est software updates, the latest pieces by one’s fa-vorite composer, or even the latestwork-in-progress by one’s favorite artist. In the caseof an artists’ or a source-code cooperative, onemight even be able to earn rebates on the subscrip-tion fee by contributing artwork or code to a proj-ect. (This is a variation on the open-source idea inwhich the most creative and productive memberscan contribute code and the vast majority of peoplewho are more interested in using the product thanin creating it can contribute money.)

For one thing, this would be an acknowledge-ment that in both music and software creation, theprocess is more valuable than a single snapshot orprogress-report (now known as a ’’release’’). It is al-ready the case that when one buys a piece of soft-ware, one does so with the implicit understandingthat one will be frequently downloading or pur-

81Scaletti

chasing updates to that software. It would be inter-esting to extend this concept to music as well.Instead of buying a single recording of a � nishedcomposition, one could subscribe to the composerand access updates to that composition, alternativeperformances of the same work, additional sec-tions, remixes, and new variations. The best sub-scriptions would also include opportunities tointeract with the creator in online master classes,interviews, or group discussions.

For the artists and programmers, subscriptionfees would provide a steadier source of income toreplace the current ’’feast-or-famine’’ bursts of cash� ow provided by the one-time purchase model.Subscribers would be like ’’investors’’ in a particu-lar artist. As such, they would � nd it in their ownbest interest to help promote that artist to a wideraudience and protect the artist against piracy(which, under this new model, would hardly beworth the effort in any case).

For the subscribers, it would mean better cus-tomer support, simply because an unhappy sub-scriber is unlikely to renew the subscription nextyear. Software developers already interact closelywith their users and bene� t from immediate feed-back. Would the subscription model foster more in-telligent dialogs on music as well? It could turn outthat musically literate subscribers might be able tooffer composers some genuinely useful observa-tions and stimulating responses to their work (inaddition to applause).

The subscription model makes it more obviousthat the creator is even more valuable than thatwhich is created. Under the old model, musicianswould effectively give themselves away for free onconcert tours, in interviews, bootleg recordings,and on the web in the hopes of selling physical re-cordings (that were owned by a record label, notthe musician). That made it seem as if the compactdisc were more valuable than the people who cre-ated its content (and who hold the potential for pro-ducing even more content in the future). Under thesubscription model, a group of subscribers could ineffect hire the musicians/programmers, investingin their future output, collectively paying the mu-sicians’s salary in exchange for wireless network

access to recorded music, ’’tele-performances,’’ andwhatever ’’extras’’ the artists choose to provide.(The corollary is that the subscribers could also � rethe composer/programmers who were not satisfy-ing their appetites for music and software.)

If digital content were available to subscriberswherever and whenever they wanted, then it mightno longer be worth the effort to ’’pirate’’ or even tostore music and software. If subscribers could ac-cess the content just as quickly as reading a localhard disk, and if the content might actually im-prove each time they access it because the musi-cians or programmers continue to work on it, thenfew people would � nd it desirable to steal the con-tent.

In game theory, optimizing bene� ts in a one-offinteraction tends to involve maximizing one’s owngain at the expense of the other person. However,maintaining a longer-term relationship consistingof multiple transactions over some period of timerequires some evidence of mutual bene� t if bothparties are to continue to cooperate. For creatorsand subscribers both, this new model would favorlong-term, mutually bene�cial relationships.

Even hardware could be sold by subscriptionrather than purchased outright. This would be anacknowledgment that there is more value in thedesign of a piece of hardware than in the actual ma-terials used. It is also an acknowledgment of the re-ality that computer hardware is inevitablyupgraded every few years. What if, instead of buy-ing a computer, you subscribed to a computer hard-ware service? Every few years, the company wouldupgrade your computer to the newer model, givingthe hardware companies a strong incentive to reuseexisting materials as much as possible. This couldprovide a steadier � ow of cash to hardware compa-nies while at the same time making them more re-sponsive to their customers, because theircustomers will be subscribing to a continuing ser-vice, not making a onetime purchase. It also makesexplicit something that is not always so obvious inthe current economy: the cost of reusing or recy-cling a product at the end of its useful life shouldbe factored into the initial (or in this case, ongoing)cost of the product.

82 Computer Music Journal

It might take some small adjustments in think-ing, but in fact we are already familiar with thissubscriber model in other aspects of daily com-merce. It is the way we pay for news services likemagazines and newspapers; it is the way we pay forcommunications services like telephone and Inter-net access; it is the way people pay for some formsof entertainment on cable television channels. Insome sense, even paying taxes is subscribing to theservices of the local and national government.(However, if one becomes dissatis� ed with the ser-vice, canceling that particular subscription could bea bit tricky.)

Acknowledgments

Special thanks to Kurt J. Hebel, my longtimecollaborator without whom Kyma and SymbolicSound would not exist in their present form.Thanks to Jean, Paul, Matt, Barry, Perry, Robin,Mike, Donald, Desiree, Chip, and Mark who havehelped run the of� ce, ship systems, and build hard-ware at Symbolic Sound. Thanks to the chartermembers of the Kyma community: Dick Robinson,Francesco Guerra, Richard Festinger, Brian Belet,John Paul Jones, Alan Craig, Frank Tveor Norden-sten, Lippold Haken, Stu Smith, David Worrall, SalMartirano, Joran Rudi, and Bruno Liberda. And, to

all of you who are now using Kyma, thank you forcollaborating with us on this lifelong project!

References

Scaletti, C. 1987. ’’Kyma: An Object-Oriented Languagefor Music Composition.’’ Proceedings of the 1987 In-ternational Computer Music Conference. San Fran-cisco: Computer Music Association, pp. 49–56.

Scaletti, C. 1989. ’’Composing Sound Objects in Kyma.’’Perspectives of New Music (27)1:42–69.

Scaletti, C. 1992. ’’Polymorphic Transformations inKyma.’’ Proceedings of the 1992 International Com-puter Music Conference. San Francisco: InternationalComputer Music Association, pp. 249–252.

Scaletti, C. 1997. Kyma Sound Design Environment.Champaign, Illinois: Symbolic Sound Corporation.

Scaletti, C. 2000. Kyma.5 Walkthrough: A Tutorial In-troduction to Kyma.5. Champaign, Illinois: SymbolicSound Corporation.

Scaletti, C., and K. J. Hebel. 1991. ’’An Object-Based Rep-resentation for Digital Audio Signals.’’ In G. De Poli etal., eds. Representations of Musical Signals. Cam-bridge, Massachusetts: MIT Press, pp. 371–389.

Scaletti, C., and R. E. Johnson. 1988. ’’An InteractiveGraphic Environment for Object-Oriented Music Com-position and Sound Synthesis.’’ Proceedings of the1988 Conference on Object-Oriented ProgrammingLanguages and Systems. New York: ACM Press,pp. 18–26.