Scott deLahunta on Thu, 23 Apr 1998 19:43:20 +0200 (MET DST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

<nettime> algorithms for dance

I mostly sit on the sidelines on 'nettime' where I find many posts extremely
relevant for my work as a researcher of the phenomenon loosely clutched
together under the heading of *Dance and Technology*. Both New and Old
Media, in all its manifestations, is directly and indirectly influencing
developments in contemporary performing arts (including dance and theater).
Part of my work has been to uncover and articulate some of the ways in which
this has and is happening... hence my interest in nettime.

Recently, on the 'dance-tech' discussion list there was a back and forth
between some programmers regarding various aspects of their work. These are
individuals involved in collaborations with dancemakers, but their
specialist lexicon was practically impenetrable for those of us who spend a
majority of our time working in the studio with 'live' versus electronic
bodies. Nothing surprising about the fact we 'dancers' couldn't follow their
discussion, and there was some suggestions that the programmers should carry
on their postings back and forth in private. But I was intrigued by this
sampling of a language so strange, so different, and was reminded of the
'nettalk' interview with McKenzie Wark published in *zkp4*. In one point in
the interview, Wark discusses this notion of 'virtual relations' as a
relation of differences that "combine their properties into still more
differences". He points at 'nettime' as embodying this "when it works 

But, 'dance-tech' is not like 'nettime', so I posted the following in an
attempt to provide a bridge across the void from the dancemakers to the
programmes side. Predictably I guess, the programmers immediately engaged in
a debate about the specific desciptions of 'algorithm' which I had nicked
from the net.

... but I didn't engage in dialogue with them, yet.



While it is a term which may be unfamiliar to some or most dancemakers, ALL
computer programmers know that an *algorithm* is a set of instructions that
directs the execution of a task. Here are some comments from the results of
checking out a couple of Introduction to Computer course homepages on the web.

An algorithm is a set of instructions with four special characteristics.
1. It is complete; all the steps are there, in the right order.
2. It is correct, it always gets the right answer.
3. It is finite; there is a stated way to know when it's done.
4. It is executable; all of the instructions can actually be carried out.
An algorithm is a set of instructions that directs the execution of a task 
  baking a cake (recipe) 
  playing music (sheet music) 
  complex mathematical calculation 

In the 1970s Trisha Brown did two performances in particular which were
based on "algorithms for dance". These were *Accummulation* and *Locus* (and
their various manifestations) . The 'algorithm' for Locus and Accumulation
can be found in several books, including *Contemporary Dance* edited by Anne
Livet. New York: Abbeville Press, Inc. 1978. The instructions or
*algorithim* for Accummulation is as follows... 

"The accumulation is an additive procedure where movement 1 is presented;
start over. Movement 1; 2 is added and start over. 1,2; 3 is added and start
over, etc., until the dance ends. Primary Accumulation accumulates thirty
movements in eighteen minutes. The 29th and 30th movements each cause the
figure to revolve 45 degrees, making a 90-degree turn with each completion
of the sequence. Therefore, a 360-degree revolution occurs in the last two
minutes of the dance, giving the audience three alternate views of the dance
before finally stopping." (TB in The Drama Review, Post-modern dance issue,
T-65, March 1975.)

The point is that this dance precisely fit the definition of an *algorithm*
as stated above: it is complete; all the steps are there, in the right
order; it is correct, it always gets the right answer; it is finite; there
is a stated way to know when it's done; it is executable; all of the
instructions can actually be carried out.

More loosely applied many of the task-dances, rule games, scores and other
devices which dancers of that period, in particular from the Judson Church
period, used for making dances could be seen as fundamentally algorithmic in
structure. There was also an ideology being applied at the time -- in the
work of Brown and others in the way they created these dance making devices
so that they could be performed by anyone. The reason they 'always get the
right answer' is based in part on an aesthetic which has evolved from the
chance work of Cage and Cunningham. The 'ideology' in particular is
expressed in Yvonne Rainer's famous 'no' manifesto written in 1965. --- "NO
to spectacle no to virtuosity etc." ---

Try it... you do not need any 'dance' training in order to perform
'accummulation'. The dance algorithm allows a 'non-dance specialist' to
create and make a dance. Just as the computer algorithms are responsible for
allowing us 'non-computer specialists' to do extremely complex things just
by manipulating the mouse and typing in the keyboard.

The interesting thing about dance algorithms like 'accummulation' is that
they can be adjusted to fit other objectives. For example, for my
composition class we have done 'accummulation w/ objects' and also used the
Locus structure (which is fundamentally the same as Laban's 26 point cube --
although I have never seen it mentioned anywhere in the T.Brown
documentation) -- by collapsing it from points in space to points on the
surface of the body and using it to construct duets.

Scott deLahunta and Susan Rethorst
Writing Research Associates, NL
Sarphatipark 26-3, 1072 PB Amsterdam, NL
tel: +31 (0)20 662 1736
fax: +31 (0)20 470 1558
#  distributed via nettime-l : no commercial use without permission
#  <nettime> is a closed moderated mailinglist for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: and "info nettime-l" in the msg body
#  URL:  contact: