This article describes the theory, design, implementation, and performance of the computer music piece Lottery. Lottery is based on a social model which promotes responsible resource sharing. Performers are temporary members of an evolving microsociety, the behavior of which is closely correlated to audible change. Lottery's goals are: 1) that its participants recognize their joint situation, and address this interdependence rationally 2) that its participants evolve their microsociety into responsible resource-sharing behavior, and 3) to produce a music which closely models the development, successes, and failures of the first two goals.

The ideas behind Lottery are derived from the work of evolutionary biologist Garrett Hardin and computer scientist/theorist Douglas R. Hofstadter.

Lottery is a computer music performance for multiple participants and computer network. The piece models a society whose participants vie for control of a common public resource. A shared musical environment constitutes this resource, and Lottery employs a coercive device to oversee its allocation. A Luring Lottery, as devised and described by Douglas R. Hofstadter in Metamagical Themas [1] is used as this coercive device.

Imagine a lottery which in no way limited the number of ballots participants could submit. Entering the lottery costs nothing, and requires little physical effort. Participants can enter as many times as they wish, simply by submitting a number representing a number of ballots. Millions of ballots can be submitted by any individual with minimal effort and minimal cost. Imagine that you enter this lottery with 100 other participants, each of which enters a single ballot. You enter 100 ballots. Of the 200 ballots entered, you submitted half, so your chances of winning are 50%, while the chances of anyone else winning is 0.5%. Obviously there is no reason to expect balloting to stay low. Participants in such a lottery would quickly realize that it only makes sense to enter huge numbers of ballots, if it weren't for one beautiful twist. The prize money awarded in such a lottery is divided by the total number of ballots received! Thus, balloting greed is rewarded by negligible prize money.

The Luring Lottery falls under a larger class of decision-making problems called prisoner's dilemmas [2]. Such problems involve a population of individuals, each of whom must make a choice in isolation. The choices made profoundly affect each member of the population with rewards and penalties. Typically, participants make the choice to "cooperate" or "defect" in some way. Rewards and penalties are distributed based on each participant's decision, and are usually calculated so that each participant in a 100% cooperating population will gain a substantial reward. Participants in a 100% defecting population gain minimally, while defectors in a mixed population gain more than cooperators.

In a Luring Lottery, cooperation constitutes submitting a low number of ballots, while defecting is characterized by submitting a large number. Typically, an individual's decision to defect is accompanied by the hope that it is a unique decision. Thus, a defector entering 100 ballots to a million-dollar Luring Lottery hopes everyone else ballots low. If so, these 100 ballots go a long way toward ensuring a victory, and will not dilute the prize much below the nice sum of $10,000 (one million divided by 100). Of course, if everyone thought like this (and why shouldn't they?), all would submit 100 or more ballots, resulting in a negligible prize. Rational behavior then, ought to be based on the realization that one's decision is likely to be duplicated by all participating members. Since cooperation is the behavior that benefits all members maximally when duplicated by everyone, one would expect every rational individual to cooperate.

Put another way, a Luring Lottery introduces a contradiction between the desire to win, and the desire to gain. The awarded prize is a quantity X/N where X is some maximum prize value, and N represents the total number of ballots submitted to the lottery. As the number of ballots N increases, the awarded prize X/N decreases. This simple and beautiful inverse relationship has tremendous power, and is inherently resistant to the hoarding and overexploitation of common resources.

My composition Lottery uses musical control over Sound States as its common resource, or "prize". A computer-driven Luring Lottery is called periodically, and the winning participant is awarded temporary control of the current Sound State. The magnitude of control given to the winner is divided by the total number of ballots submitted. Thus, participants find themselves in a simultaneously cooperative and competitive environment, where they must strike a balance between the desire to control the piece, and assuring that such control will not be diluted to a meaningless level. This behavior is explored in a highly quantified manner, where the evolution of the performers' microsociety is readily observed.

In an article called "The Tragedy of the Commons", evolutionary biologist Garrett Hardin writes, "The social arrangements that produce responsibility are arrangements that create coercion" [3]. This view of society holds that each of a society's members can only be expected to act responsibly if coercive devices are established. Without such devices, disaster is ensured by self-serving behavior duplicated on a large scale. Hardin argues that an appeal to voluntary cooperation is hopeless. Altruists responding to such an appeal will simply be deprived of a society's resources and will fail to proliferate. Selfish members will gain the lion's share of resources, and after a short time will overwhelm the cooperators in number, resulting in a condition quite the opposite of what was intended.

Central to Hardin's thesis is the notion that an individual's behavior can only be analyzed by assuming that it will be duplicated by each member of society. He defines irresponsible behavior as individual behavior which upon duplication results in a degraded condition for all members of a society. Responsible behavior is the opposite: behavior which upon duplication enriches conditions for all members. Having demonstrated that an appeal to voluntary cooperation is flawed, Hardin calls for coercive devices to ensure that individuals behave responsibly. That is, he calls for the establishment of social devices which would cause responsible behavior to be chosen even by society's most selfish members.

In response, Douglas Hofstadter argues that external coercive devices may not be needed at all. An individual need only recognize that his or her behavior is likely to be duplicated by others. When faced with a choice, the rational individual will recognize that a reasoned decision will probably be duplicated by thousands of others facing the same choices. The rational individual will therefore make a decision which reason dictates will result in an enriched life when duplicated by thousands of others. This decision can therefore benefit all members of society, and yet be motivated by self-interest. The result is a society of individuals each of which need only make self-serving rational decisions, the collective sum of which ends up benefiting all members of society! Only the irrational individual will choose to behave irresponsibly, as that individual is actually promoting a degraded condition for all, including himself [4]. Thus it falls upon the social engineer to ensure that all members of a society recognize their joint situation.

How likely is it that an individual will recognize that his or her decisions will be duplicated on a large scale? Hofstadter explored this question with a version of the prisoner's dilemma. In this version, weighted monetary prizes were awarded to participants based on their decision to "cooperate" or "defect". An analysis of the weighting reveals that each participant will receive a greater amount of prize money if all participants cooperate than if all defect [5]. If the population's decisions are mixed, defectors will always do better than cooperators. Since the decision to cooperate or defect is a rational one, Hofstadter expected it to be also a universal one. (By his analogy, one would expect the same answer to be submitted by all students who were asked the same arithmetic problem, as the answer is deduced rationally). Once this universality is recognized, the participants ought to have realized that they would all submit the same decision. The question now becomes, "since all will submit the same decision as me, what decision would be most self-serving?" The decision to cooperate fits this criterion, and should have been made by all. Twenty individuals were asked to participate yet none recognized their joint situation. The decisions were mixed, and the defectors gained more than the cooperators.

As a follow up to this disappointing experiment, Hofstadter opened a Luring Lottery to all readers of his column. The maximum prize was $1,000,000, which would be divided by the total number of ballots received. Individuals were asked to indicate the number of ballots they would like to submit by writing this number on a postcard and sending it to Hofstadter. Again, the participants' behavior was disappointing. Some entries were so fantastically huge, that their actual values defied mathematical analysis. In the end, in Hofstadter's words, "I don't know who won, and it doesn't matter, since the prize is zero to such a good approximation that even God wouldn't know the difference" [6]. Apparently this coercive device did not do its job. Participants completely lost sight of their joint situation and behaved irrationally, ruining the chance for anyone to win a meaningful prize.

I was intrigued and disturbed by the results of these experiments. I wondered, what if Hofstadter had run the lottery again? Would the society of participants have learned from this disaster and adjusted their behavior by submitting fewer ballots, or willfully exclude themselves from the lottery? What if the lottery were run on a daily basis [7]? Would we witness a social evolution toward responsible rational behavior, or would we repeatedly witness irrational resource-hogging? Few are in a financial position to risk $1,000,000 for the sake of social research. Nevertheless the experiment could be carried further, if the prize were taken out of the domain of money.

I decided to introduce a Luring Lottery as a coercive device in a musical performance, where control over musical events was the resource shared by members of society, not money. The lottery would be repeated often. Rather than faced with a "one-shot deal", the society of participants would be offered the opportunity to learn of their joint situation through experience, not a priori theory. They would have numerous chances to learn from their mistakes and hopefully, evolve from self-serving destructive behavior into self-serving constructive behavior.

The software of Lottery was coded by myself during my residency at The Center for Contemporary Music at Mills College (CCM). The programming language used was Hierarchical Music Specification Language (HMSL). HMSL is an object-oriented superset of the Forth programming language, and was developed by Phil Burk, Larry Polansky, and David Rosenboom at the CCM. HMSL was designed to be a non-stylistically biased programming environment for experiments in music composition and performance [8]. HMSL's MIDI toolbox, event scheduler, and Object Development Environment facilitated the development of many aspects of Lottery.

Initial sketches and tools for Lottery were coded in February, 1990. I developed the scheduling logic and data structures on an isolated Commodore Amiga 1000. After a certain point, development on a lone computer had to stop, as it became increasingly difficult to emulate the multi-Amiga network that Lottery would eventually run on. The two pronged problem of coding a robust multi-computer system and emulating the network on one machine rapidly grew out of proportion. The emulation became a project in itself, complete with its own source of errors, and its development was aborted in favor of waiting for access to multiple computers.

Through the CCM residency I gained access to the necessary equipment, and with the aid and advice of Burk, Polansky, and Robert Marsanyi, a preliminary version of Lottery was completed during the first week of March. Significant changes were implemented after the first rehearsal. The piece was publicly performed by Burk, Polansky, Marsanyi, and myself at Mills on April Fool's Day, 1990.

The current version of Lottery calls for any number of performers, each with an Amiga computer. One Amiga is arbitrarily designated to be the host, the others are called remotes. All Amigas are linked together via MIDI (Musical Instrument Digital Interface). Each Amiga's MIDI output is sent to the next Amiga's MIDI input, until a ring is completed (Fig. 1). MIDI is used here purely as a networking protocol. It is not used to drive synthesizers or samplers, or to directly produce any sound. By sending system exclusive MIDI data packages through the MIDI ring, computers may communicate with one another. The software interprets these data packages appropriately, allowing for the high level events and decisions of the Luring Lottery to be passed to all computers and participants.

Each Lottery performer has four software screens to view on the Amiga, each dedicated to a different aspect of the piece. There is HMSL's own Shape Editor: an interactive "point and click" data editing screen with which the performer may construct Sound States (Fig. 2).

HMSL affords the programmer tools to create custom screens as well. Lottery employs three custom screens. The Lottery Control Screen consists of brief instructions, and buttons with which the performer may select the number of ballots to submit to the current lottery (Fig. 3).

The Voting History Screen displays each participant's name and the number of ballots he or she submitted for every lottery since the piece began (Fig. 4).

Finally, the Current State Screen graphically displays the current Sound State of the piece (Fig. 5).

The host Amiga functions as the executor of a Luring Lottery every thirty seconds. This machine is principally responsible for collecting ballots from remote machines, choosing a winner, and informing the rest of the machines of the results. The host performs other duties as well, such as overseeing the initialization of the MIDI ring, generating a CSound score of the performance, and keeping a log of the performance, all of which are discussed below under Technical Notes.

The sound generation of Lottery is handled entirely by the audio hardware of the Amigas [9]. Each Amiga is capable of producing four independent audio waveforms and is patched into a public address system. Each new lottery has the potential of changing the sound environment by changing any or all of the waveforms played by the Amigas. Because each machine can contribute four independent waveforms, Lottery's sound environment can achieve great complexity and density with few machines.

A Luring Lottery can be implemented in an indefinite number of ways, as the lottery itself is a very high level formal notion. It can be realized with prize money, vacation days, acreage, degrees of musical control, or any other quantifiable common resource. I wanted Lottery to be both highly quantifiable and musically interesting. It seemed very important that the audible change experienced during the piece would correlate transparently and intuitively to the high level formal structure of the Luring Lottery. To these ends, I chose to define a Sound State as a collection of audible waveforms, each with its own harmonic spectrum and playback period. The parameters defining a Sound State would then be highly quantifiable, being lists of partial numbers, their magnitudes, and a detuning value for each waveform. I found that constructing the common resource of Lottery from harmonic spectra provided the piece with an audible resource that paralleled balloting behavior clearly.

As each Amiga is capable of playing four independent waveforms, a Sound State using a network of four Amigas may consist of up to sixteen waveforms. During the interval between lotteries, the Sound State does not change. It is a static audio environment comprised of these sustaining waveforms, each with its own harmonic spectrum and detuning value. Despite the non-changing nature of the Sound State, there is often a great deal of sonic activity generated by lower detuned partials beating against each other, and higher detuned partials shimmering against each other. The reader may imagine harmonically complex sustained organ chords, changing either radically or with extreme subtlety every half minute.

Each new Sound State, realized every thirty seconds as the result of a new Luring Lottery, is a weighted mix of the piece's previous Sound State and the winning Sound State. The mix is determined by the total number of ballots submitted during a given lottery, where a high total results in minimal weight being given to the new Sound State, and a low total maximizes the change from the old to the new Sound State. If participants in a Lottery performance submit a huge amount of ballots, Sound States will not change noticeably. In fact, a winning Sound State would completely replace the old Sound State only if a total of exactly one ballot were submitted by the group. Thus change is governed by a complex interaction between the intentions of the performers and the scaling enforced by the lottery mechanism. The lottery process can introduce exceedingly subtle changes between Sound States when balloting is high through its use of scaling; changes that would be nearly impossible for any single participant to specify directly.

During the thirty second interval separating successive lotteries, each performer may construct a unique Sound State, which he or she would like to hear implemented. Using the HMSL Shape Editor (fig. 2) the performer may select any one of the waveforms being played by any Amiga. The performer may design the harmonic spectrum of this waveform with the mouse, by raising or lowering the magnitudes of any of 127 partials. This process can be repeated for any subset of available waveforms. Using the Lottery Control Screen (fig. 3), the performer may inform the network as to which of the waveforms ought constitute a Sound State, by highlighting the wave numbers in a grid labelled "Select Waves". For each selected waveform, the performer may also select a value by which to change its playback period using a grid labelled "Detune Waves". Each performer may also submit any number of ballots to the lottery using the Lottery Control Screen. The host machine selects a winner at random, and implements the winner's Sound State.

One of the most powerful resources available to performers is the Voting History Screen (fig. 4). This custom screen can be used to look up the balloting history of all performers for every lottery since the piece began. Balloting is secret only during the balloting process itself. After each lottery, the balloting for each participant is made public. In this way, the society receives a direct report on how it is behaving. This access to history introduces a powerful psychological coercive device, perhaps more powerful than the Luring Lottery mechanism itself! If a performer is balloting very high, everyone will know who is "ruining it for everyone".

The first rehearsal of Lottery ought to have been public. It was during this time that the performers' behavior was the most radically evolutionary and self-aware. The "microsociety" evolved most painfully during this rehearsal, as we witnessed group behavior ranging from "arms escalation" (all participants begin to submit higher and higher numbers of ballots), "de-escalation" (participants see the futility of their joint behavior and begin dropping out of the balloting process, or submitting very low counts), "peace" (a group behavior of low balloting), and "de-stabilization" (one participant starts to submit significantly more ballots that the rest of the group, starts to win disproportionately often, and others follow suit) [10].

By the time the piece was performed, the group as a cooperative organism had already been established. The premier performance was a rather tame version of the piece, though what it lacked in social storminess, it gained in a cooperative music making.

The biggest flaw in any attempt to isolate the effect of the Luring Lottery on the behavior of the performing group is the assumption that audible change is desirable at all. Any participant who makes the aesthetic decision to freeze the Sound State of the piece indefinitely, or to prevent it from rising above silence in the first place, may do so with 100% success simply by submitting astronomically high ballots to each lottery. Thus, instead of the individual's desire being scaled down by balloting, it is the balloting itself which ensures that the individual's desire is achieved. The mechanism of the Luring Lottery itself can be used to achieve ends precisely counter to what it was designed to enforce. There is no obvious solution to this problem. Perhaps the piece needs to provide the performing group with a way to lock out renegade individuals who use the balloting process to enforce stasis. This would constitute something like a penal system, which is a notion I would regret introducing to the piece, as it runs counter to the philosophy of a self-regulating society. I would rather trust that eventually such behavior would collapse under the weight of the boredom it produces.

This problem is, of course, inherent in the Luring Lottery itself, which assumes that participants universally want a maximal share of the prize. This assumption discounts individuals who may care nothing for the prize, or are mean-spirited and want to assure that nobody gets a prize, or are morally motivated and want teach everyone the lesson that competition for a prize is wrong. Each of these character types might submit a huge number of ballots for radically different reasons, none of which have to do with personal greed.

There is a subtle difficulty in correlating the extent of audible change with the balloting behavior of the group. The piece is designed so that change is maximized if balloting is minimized. What factors are responsible for the degree of change perceived? Even with a high ballot count, a greatly scaled down addition of complex partials into a Sound State of partials in simple relationships might be perceived as a big change. Conversely, even if balloting is low, a new Sound State which is either very similar spectrally to the previous Sound State, or with partials that are in simple ratios to the previous Sound State, may be implemented maximally but with a low perceived change. The software currently takes a straight weighted average of all the parameters of the old Sound State and all the parameters of the new Sound State. Perhaps the software should be more sensitive to the psychoacoustics of the two Sound States by first calculating the psychoacoustic "distance" between them, reflecting the potential for change. Given this calculated distance, it would be reasonable to scale the degree to which the succeeding Sound State is implemented not only by the total number of ballots submitted, but by a factor which takes the potential difference into account.

Finally, more information must be made available to the audience. The current implementation provides performers with a wealth of information. The performers' experience is a complex sum of hearing the sound around them, thinking about the sound they want to implement, balloting strategy, the examination of the balloting history of others, the examination of the current Sound State, and the act of performing. As such, the thirty second interval passes by very quickly for performers. In fact, performers sometimes get so occupied with waveform editing, or examining and devising strategies, that they will often miss an opportunity to participate in a given lottery. The audience's experience is radically different. They see performers intently watching their computer screens, sometimes furiously active with mouse and computer keyboard. Little realtime information as to why the performers are excited reaches the audience. The primary experience from the audience's perspective is an audible change every thirty seconds or so. The musical experience is clearly only one aspect of Lottery, and it is a mistake to limit the audience's perception to this experience.

An immediate solution would be simply to have video projectors or large monitors display each performer's private terminal for the audience. Future versions should have one or more terminals linked into the network, which audience members may access freely. These terminals would provide the audience with at least as much information as is provided to participants, providing all the custom screens that are provided to performers. Perhaps a running commentary should be available on these terminals as well, provided by non-participating performers. Speculations on, and summaries of balloting strategies could be discussed on these terminals in an open text-based forum. Larger video monitors or video projectors would make these terminals visible to audience members who choose not to personally interact with the terminals.

Lottery succeeds reasonably well in fulfilling the three goals as stated in this article's abstract. Participants were extremely aware of their joint situation, and after a rehearsal and extensive discussion, developed balloting behavior that distributed control among the performers more or less equally. The sound produced by the piece modeled the group's behavior well despite the caveat above concerning "distance" problems between old and new Sound States. Cooperation generally resulted in performers' ideas being realized and clearly heard. Lack of cooperation resulted in lack of change, and precipitated a group effort to alter its behavior. As such, the Luring Lottery was very much felt to be at the heart of music making, and was very potent in setting the philosophical tone of the collective activity.

Whether or not the behavior adopted by the group constitutes "responsible resource sharing" is an open question, however. It is equally likely that the group developed something like voluntary asceticism. The group never established a definition of responsible behavior, that is, behavior as defined by Hardin, which is duplicated by all and which benefits each member maximally. Our group's behavior developed intuitively into low balloting, which, if done for reasons of voluntary cooperation, precipitated the right behavior for the wrong reasons. Given the personalities of the group, it is quite likely that egalitarian sharing of resources would have resulted simply by agreeing to do so, rather than employing an elaborate coercive device. I would welcome a highly uncooperative group of performers to test Lottery more severely. Then perhaps we can discover utterly selfish behavior strategies which have the same result as voluntary cooperation.

Since the initial implementation of Lottery, I have examined a more formal approach toward defining a self-serving strategy employable by each participant, which maximizes each participant's personal gain. This model requires that each individual have access to a random number generator, like a software die with 100 faces, which could be "rolled" to determine whether or not a participant enters a given lottery. With some participants willfully "rolling themselves out" of a given lottery, the remaining ballotters stand a greater chance of gaining significant control. It is a unified strategy, since its use by all could end up benefiting all equally, as long as all chose the same low probability of participating.

The probability that an individual chooses to decide whether or not to participate in a given lottery shall be called the "Participation Probability". With four performers, a reasonable participation probability for each is 0.25, meaning each performer has a 25% chance of participating in a given lottery. If each of four performers participates in each lottery with a probability of 0.25, then the probability of each lottery having exactly one ballotter (and thus exactly one winner) is maximized. A lottery with one ballotter gives that individual complete control over the piece, provided that this individual submitted exactly one ballot. As long as everyone follows this 0.25 participation strategy, and submits exactly one ballot, each individual can look forward to having complete control over the piece more than by any other similar strategy. (Submitting more than one ballot with a participation probability of 0.25 amounts to "shooting yourself in the foot": one person is likely to participate, but is singlehandedly responsible for diluting his or her own prize). A good argument can be made to boost the 0.25 participation probability a little, to minimize the chance of a given lottery having no winner at all. The boosted value should reflect a balance between the society's desire to have exactly one ballotter, versus the desire to avoid a lottery where there is no ballotter at all.

Figure 6 graphs such strategies by showing the effect of participation probability versus the expectation that a lottery has a given number of ballotters. It is assumed that for each participation probability, each of four individuals participate with this probability. For instance, the unbroken line plots the effect of a universally agreed-upon participation probability (horizontal axis) against the expectation that a given lottery has exactly one participant. Notice that the curve is highest when all agree upon a 0.25 participation probability, yielding a better than 0.40 expectation that a given lottery has exactly one ballotter. The curve drops to zero as the participation probability increases to 1.0, reflecting that it is less and less likely that there be exactly one ballotter as all individuals participate with higher and higher probabilities. Notice also that the curve plotting the likelihood that a given lottery has four ballotters (the dash-dot-dot curve), is maximized as the participation probability is maximized. Clearly, if each individual chooses a participation probability of 1.0 (certainty), then it is certain that a given lottery will have four ballotters, resulting in a maximally diluted prize. Five curves are plotted, each reflecting the effect that participation probability has on the expectation that a given lottery has 0, 1, 2, 3, or 4 ballotters.

This participation strategy would be voluntary, of course, and would only work as well the good faith with which participants use it. The next versions of Lottery will have this tool available to its participants. A more quantifiable notion of cooperation will thus be examined. I think of Lottery as an ongoing project, separable into two components: the theoretical framework which will stay essentially the same throughout future versions, and the musical implementation which is mutable. The theoretical framework consists of the pure notion of the luring lottery, and all the philosophy, discussion, and issues inherent in this prisoner's dilemma. The musical implementation, one of which has been described in this article, and to date remains the only implementation that was ever realized, holds great promise for future experimentation and growth. Versions using common resources of melodies, rhythms, and timbres are possible and have been discussed by Polansky, Burk, Marsanyi, and myself. Using live musicians as a common resource is another attractive possibility, where lottery participants would vie for the opportunity to conduct live improvisation. I find this dualism to be the most compelling feature of Lottery. On the implementation level, Lottery is a musical performance piece, and as such, demands much from my own creative resources as composer, from participants as music-makers, and from the audience as listeners. On the theoretical level, Lottery addresses human issues that transcend its musical implementation: issues of cooperation, defection, competition for resources, individual ego, group survival, and the contribution of theory to the evolution of human society.

1) IMPLEMENTATION OF SOUND STATES

The implementation of a Sound State makes use of the Fast Fourier Transform [11]. A fixed-point FFT was implemented in JForth and optimized with 68000 assembly . My colleague Joe Ravo provided me with the code on disk, as he had begun to port it to a 32 bit Forth on the Atari computer [12]. Robert Marsanyi and I finished porting the code to Amiga JForth in August, 1989. I optimized the FFT considerably after that, speeding it up enough to be usable in a performance environment.

This raw FFT code was then covered with a layer of object-oriented HMSL code, which made it simple to run forward and inverse FFT's on HMSL's audio sample objects. Lottery only uses the inverse FFT, as it must create an audio waveform from the specifications of its harmonic spectrum. Whenever a new Sound State is implemented, each machine must be informed of the new environment. Each machine must decide whether the affected waveforms are running on its own audio hardware, in which case, it must perform the inverse FFT. The top level routine is shown below. This code loops through each spectrum of the winning Sound State, held in a data structure called scaled-winning-env. The routine calls the subroutine do.I.own.this? to decide whether the waveform belongs on its own hardware or not. If so, it copies the spectrum to a private, reusable data structure with the routine copy.mag, performs some necessary housekeeping with set.current.all, and finally performs the inverse FFT with the routine ifft.from.curr. The HMSL word da.period! is used at the end of the routine to set the playback period of the waveform. The period offset specified by the winning Sound State is added to a constant base period.

: HANDLE.NEW.ENVIRONMENT ( -- )
\ ." REMOTE: handling scaled-winning-env" cr
 update.lottery-partials
 many: scaled-winning-env 0 do
        i 0 ed.at: scaled-winning-env   ( -- wave#)
        dup do.I.own.this?      ( -- wave# flag)
        IF ." running IFFT" cr
          i copy.mag    ( -- wave#)
          set.current.all       ( -- wave#)
\ da.channel, mag, and sample now set
          ifft.from.curr        ( -- )
          curr-sample @ use: [] ( -- )
          i 1 ed.at: scaled-winning-env ( -- detune-period)
          start_period + da.period!     ( -- )
        ELSE drop
        THEN
 loop
;

Lottery's network of Amigas is connected via MIDI. Each Amiga's MIDI output is sent to the next Amiga's MIDI input, until a ring is completed. Messages pass in one direction only through this ring. A message is encoded as a MIDI system exclusive data package (sysex). HMSL's MIDI parser is used to process incoming system exclusive messages properly. The first value of a Lottery sysex packet is a machine ID, and is used to identify to which machine the message is being sent. The second value in the package is a message ID code, indicating what kind of message is being sent. After this ID, the body of the data is sent. This data varies depending on the message type. For instance, if the message were only to send a ballot count, the package would be only a few bytes long. On the other hand, the message might transmit a winning Sound State: all the partial and magnitude information for indefinite number of waveforms. This can be quite large.

Each Amiga owns a unique ID that is calculated during the network's auto-configuration process. Another value, calling_all_units, specifies that a message is meant to be heard by all Amigas on the ring. Messages either originate at the host and are sent to all or a specific remote machine, or they originate at the remote, and are sent to the host. There is never any need for remote machines to communicate with each other directly.

Since messages must pass through machines for which it may not be intended, the software must pass along unharmed any messages meant for other machines, and it must trap messages meant for its own machine. The following routine contains the logic necessary to either trap or pass a message through. It is the top level routine to receive incoming sysex, and is thus responsible for its top level handling. This broad responsibility necessitates that the code handle the auto-configuration of the network, as well as the chores of the piece itself. The portion of the code responsible for deciding whether an incoming message belongs to its own machine or not, is in bold.

: LOTT.HANDLE.SYSEX ( vendor -- )
 dup hr_lott_init = 
 IF handle.init.code
 ELSE   sysex-thru? @ 
        IF midi.start.sysex dup midi.xmit 
        THEN  ( -- vendor)

        dup machine_id = swap calling_all_units = OR 
\ if this message is being sent to this or all Amigas, then...
        IF receive.sysex.14     \ ...read message ID...
                IF lott.process.sysex   \ ...and process the message,
                ELSE ." lott.handle.sysex didn't get message code" cr
                THEN
\ otherwise, pass the message along.
        ELSE    ." passing traffic..." flushemit 
                swallow.sysex ." done" cr
        THEN
 THEN
;

Portions of this code are examined below.

: LOTT.PROCESS.SYSEX ( code -- )
 CASE 
 hr_sending_scaled_env OF ..receive.scaled.env ENDOF
 rh_sending_env OF ..receive.env ENDOF
 rh_sending_ballots OF ..receive.ballots ENDOF
 hr_lott_notify OF swallow.sysex ..New.Lottery ENDOF 
 hr_lott_ten_sec_warning OF swallow.sysex ..Ten.Sec.Warn ENDOF 
 hr_req_win_env OF swallow.sysex ..Send.Env.To.Host ENDOF 
 hr_handshake OF swallow.sysex ..handshake ENDOF
 hr_send_name OF ..send.name.to.host ENDOF
 hr_who_won OF ..receive.who.won ENDOF
 rh_sending_name OF ..receive.name.from.remote ENDOF
 hr_config_code OF ..config.from.host ENDOF
 hr_sending_vote_hist OF ..receive.vote.hist ENDOF
 dup . ." is an unrecognized sysex message code!" cr swallow.sysex
 ENDCASE
;

hr_sending_scaled_env is an ID informing the remote that the host is sending a new Sound State. The remainder of the data in this message constitutes this Sound State's parameters, and will be read by the routine ..receive.scaled.env

rh_sending_env is a code used by a winning remote Amiga to inform the host that the remote is sending its Sound State to the host for scaling and redistribution. The host responds with the routine .. receive.env, which parses the data properly.

rh_sending_ballots informs the host that the remote is sending balloting information. The host reads the data which follows this ID as such with the routine ..receive.ballots.

Perhaps the reader can tell what some of the other ID's do, given their mnemonics.

Lottery autoconfigures the MIDI ring, meaning that no code has to change to accomodate more or less machines being linked together. The autoconfiguring algorithm was suggested to me by Phil Burk. The process is begun by the host, which dispatches a kind of software scout to see if any remotes are on the network. The first remote to receive this message traps it, reads the unique ID contained in the scout's message, and announces itself to the host. The next time the host sends out the scout, the remote passes the scout through, to be trapped by the next remote in the ring. This process is repeated until no remote traps the message, and the host receives the scout back. At this point, the host behaves as though it were a remote machine, and assigns itself the outgoing ID. When this machine, behaving as host again, notices that the incoming ID is the same as its own ID, it recognizes that the ring has been completed. All remotes have been identified, polled for their user's name, and are finally informed as to how many machines are on the network, and what everyone's name is. Each remote now knows how many waveforms are available (four times the number of Amigas), and what every participant's name is.

The following routines are at the core of the autoconfiguration process. Discussion follows each example.

: SNIFF.FOR.REMOTE ( -- )
 1 id-sent-out +!
 ." Host sniffing..." cr
 midi.start.sysex hr_lott_init midi.xmit
 id-sent-out @ midi.xmit.14
 midi.end.sysex 
 midi.flush
;

: RESPOND.TO.HOST.INIT ( -- )
 machine_id host_machine_id = 
 IF handle.finished.ring
 ELSE trap.id
    get.user.name
    send.name.to.host
    machine-inited? on
 THEN
;

: HANDLE.FINISHED.RING ( -- )
 ." ring finished" cr
 swallow.sysex
 machine-inited? on
 ." There are " id-sent-out @ . ." machines in the net" cr
 id-sent-out @ -> number_of_participants
 print.names
 ..configure.lottery
 send.config.to.all     \ send all remotes a summary of the network
 start: lottery-job     \ First lottery will start in 30 seconds
;

3) CSOUND SCORE

CSound is music software capable of generating high quality 16-bit sound files, by calculating audio waveforms from the composer's specifications. It writes these waveforms directly to hard disk. This sound file can be read and played back later by digital-to-analog audio hardware. CSound is currently available on a number of platforms such as the Mac II, Sun workstations, and the NeXT computer [13].

As described above, the parameters which define the Lottery's Sound States (partials, their magnitudes, and detuning values) are used to generate audio waveforms in realtime on the Amiga network, which are played by the Amiga's 8-bit audio hardware. Simultaneously, and transparently to the performers, these parameters are also being logged to a text file in a format directly readable by CSound.

The text file, or score file created by Lottery calls on CSound to generate the same performance that was heard in realtime. The advantages of using CSound include its much higher audio quality. Its disadvantage is that CSound cannot calculate these waveforms in a realtime interactive performance environment. However, CSound is perfectly happy to generate a 16-bit recreation of the Lottery performance in non-realtime, by reading a score file generated by HMSL software.

A final audio version of a Lottery performance then, ought consist of a digital recording of the live Amiga audio, played in parallel with the sound file generated offline by CSound. I was intrigued at the notion of hearing these two realizations simultaneously. I am very attracted to the subtle distortions generated by the Amiga audio hardware, and think a clinically clean CSound realization would be a perfect complement. Such a recording has still to be produced. It ought to be accompanied by the performance log generated by Lottery software. This log is simply a text file detailing each participant's balloting behavior, and who won each lottery.

With the aid of Phil Burk, it was decided that the most efficient way to implement the CSound score is with CSound's standard function number 10. Alternative strategies were considered, with calculation times that could have resulted in CSound running full time for weeks to regenerate the score! Function 10 is much more efficient, though not realtime, and is basically a list of partials and their magnitudes. We specified that instrument i1 employ this function to generate its waveform. Instrument i1 expects parameters that define what time it turns on the waveform specified by function 10, how long this waveform is to last (always 30 seconds), at what frequency the waveform is to be played (reflecting the Sound State's detuning value), the waveform's amplitude, and a stereo pan value.

The following routine is responsible for writing out the instrument's specifications in CSound format. Besides fulfilling its required function, this routine also assigns a random stereo pan value to each waveform. Comments were left in the code, and describe the code line by line.

: WRITE.CSOUND.INS { lott-num index -- }
 cr ." i1" space        \ write the instrument name
 lott-num 30 * .        \ on-time is 30 sec times the lottery number
 30 .           \ dur: thirty seconds per lottery
 index 0 ed.at: lottery-environment     ( -- detune-value)
 start_period +                 ( -- detuned-period)
 256 da.fl->p                   ( -- freq)
 .                                      ( -- , print frequency)
 amp-per-ins @ .                        ( -- , write out amplitude)
\ now choose a random left/right pan value
 100 choose int->pan     ( -- , 1.00=left, 0.00=right, 0.50=center)
 function-number @ . cr
;

\ We are using csound standard function #10
\ format is:
\ fn 0 4096 10 p1 p2 p3 .. p127
\ where fn = f1, f2, .. f(number-of-waveforms * number-of-lotteries)
\ p1, p2, p3 .. are magnitudes of partials 1 .. 127

: WRITE.CSOUND.FUNCTION { index -- }
 cr
 ." f" function-number @ . space ." 0 4096 10" cr 
 dimension: lottery-environment 2 do
        index i ed.at: lottery-environment .
        i 10 mod 9 = IF cr THEN
 loop
 cr
;

; Nick Didkovsky
; lottery.sco
; csound version of live Lottery Piece
; Waves created by function 10 - list of magnitudes of partials
; instrument i1 bangs a wave defined by this function
; instrument parameters are:
; ins time dur freq ampl pan wave

; lottery #0 

; lottery #1 

; lottery #2 

f1 0 4096 10
0 0 0 7 0 0 0 0 
0 0 5 0 0 0 0 0 0 0 
0 3 0 0 0 0 0 0 0 0 
0 0 2 0 0 0 0 0 0 0 
0 0 0 0 1 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 

i1 60 60 104 10666 0.61 1 

f2 0 4096 10
0 0 7 0 0 0 0 0 
0 0 0 0 0 0 0 3 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 7 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 2 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 7 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 2 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 

i1 120 60 104 10666 0.41 2

1. Hofstadter, Douglas R., Metamagical Themas, Scientific American, Vol 248, Issue 6, page 14, June 1983
Back to article

2. See Poundstone, William, Prisoner's Dilemma, Doubleday, 1992 for an excellent history and analysis of decision-making games that fall under the category of prisoner's dilemmas.
Back to article

3. Hardin, Garrett, The Tragedy of the Commons, Science, Vol. 162, No 3859, pages 1243--1248, December 1968)
Back to article

4. Hofstadter, Douglas R., Metamagical Themas, Scientific American, Vol 249, Issue 3, page 27, Sept 1983)
Back to article

5. These are the classic criteria which define that category of decision-making games called prisoner's dilemmas. As is typical of these games, one defector in a group of cooperators will reap great gains when compared to the cooperators, while a defector in a group of defectors will gain minimally. A familiar version of this game is the game of Chicken, where two cars are driven toward each other by individuals who must decide to swerve (cooperate) or drive straight (defect). If both cooperate, both lose minimally by staying alive, but win no prestige. If both defect, both lose maximally by losing their lives. If one defects and the other cooperates, both stay alive, but the defector has won more by gaining prestige, while the cooperator loses by being branded as a "chicken".
Back to article

6. See Hofstadter, Sept 1983
Back to article

7. For a fascinating description of repeated, or iterated, prisoner's dilemmas, see Poundstone, pp. 236--248. Robert Axelrod's tournaments are described, which pitted contestants against each other in iterated dilemmas. One result of Axelrod's work is the opinion that given a one-shot deal, defection is to be expected. Only when these dilemmas are iterated, can more interesting strategies and behaviors be expected to develop.
Back to article

8. Polansky, L., Burk, P., with Rosenboom, D. 1990. "HMSL: A Theoretical Overview." In Perspectives of New Music, Summer.
Back to article

9. For technical coverage of the Amiga's sound hardware, see Peck, R., Deyl, S., Miner, J., Raymond, C., The Amiga Hardware Reference Manual, Addison Wesley, 1986
Back to article

10. These war/peace terms were Phil Burk's and my own somewhat fanciful inventions. However, it is not accidental that game theory and prisoner's dilemma strategies were of great interest to American military intelligence, and they seem to invite these descriptors. While the prisoner's dilemma is a pure mathematical and behavioral problem, it was defined and its military applications studied by the RAND corporation as early as 1950. See Poundstone, p. 8.
Back to article

11. For a discussion of the Fast Fourier Transform and its impact on signal processing and analysis, see page 56 of Dodge, C., and Jerse, T., Computer Music: Synthesis, Composition, and Performance, Schirmer Books, 1985.
Back to article

12. The heart of the FFT code was taken from Dr. Dobb's Journal 1984 special Forth issue.
Back to article

13. For a brief history of software synthesis languages like CSound, see Dodge, Jerse, pages 12--19.
Back to article
 
 

Event Scheduler - That part of Hierarchical Music Specification Language which is responsible for scheduling the timing of musical and other software events. The generality of the scheduler affords the programmer the capability of scheduling not only musical events (notes, chords, glissandi, etc) but functions as well (such as scheduling a lottery every thirty seconds).

HMSL - Hierarchical Music Specification Language. HMSL is music composition and performance software, and was developed by Phil Burk, Larry Polansky, and David Rosenboom at the Mills College Center for Contemporary Music. HMSL was designed to be a non-stylistically biased programming environment for experiments in music composition and performance. It is built upon the Forth programming language: JForth on the Commodore Amiga, HForth on the MacIntosh.

MIDI - Musical Instrument Digital Interface. "MIDI is an industry standard for the electronic exchange of musical information among a variety of computer-assisted musical devices, such as synthesizers, samplers, notation and sequencing software." (From Burk and Polansky, HMSL Reference and User's Manual, Frog Peak Music, 1991) The generality of HMSL's MIDI routines allows the programmer to use MIDI to pass non-musical messages as well.

MIDI Toolbox - Those software routines available in HMSL that handle transmission and reception of MIDI data from and to HMSL. The MIDI parser, for instance, is a collection of redefinable routines (called vectors) that fire depending on what kind of MIDI information is received by the computer running HMSL (note-on data, note-off data, pitch bend data, etc). The programmer may plug his or her own functions into the parser to handle the variety of MIDI input as it arrives, providing one function to respond to note-on data, another to respond to pitch bend data, etc. The MIDI parser ensures that only note-on data will be sent to the note-on vector, and that only pitch bend data is handled by the pitch bend vector. Thus the programmer may easily select and exploit that part of the MIDI input stream which is relevant to a particular situation.

Object Development Environment - Also known as ODE, this is the layer of HMSL software which provides the programmer with object-oriented programming capabilities. Object-oriented programming is characterized by software structures known generally as object classes, which contain both data and functions to handle the data. Each class of object may define its own unique collection of data fields and functions. For instance, an 'employee' object class might contain a data field for the employee's name, another for salary, and another for social security number, as well as functions which handle tasks such as paying the employee's salary, printing memos to or from the employee, etc. The advantage of object oriented programming becomes apparent when software must efficiently accomodate a new kind of employee (part time consultant, for example). A new class of object could be written which inherits all of the features of the general employee object. Only a few new data fields and functions unique to this new class would have to be added by the programmer.

Partials - Given a fundamental frequency, partials are those frequencies making up a waveform which are whole number multiples of the fundamental. For instance, given a fundamental of 50 Hz, the second partial is at 100 Hz, the third at 150 Hz, the fourth at 200 Hz, and so on.