<nettime> software choreography

[Scott deLahunta <sdela@ahk.nl>]

Duplex/ ChoreoGraph: in conversation with Barriedale Operahouse

edited by Scott DeLahunta

2 May 2002

Background:

Barriedale Operahouse is a London/ Vienna based artist group founded in 
1994 under the direction of Michael Klien and Nick Mortimore. In mid 1997, 
they began to develop the concept for a software tool for “choreographers, 
directors and even designers” that could help to structure and control the 
various components of any performance event, i.e. sound, video, movement, 
etc. Eventually, they settled on the title ‘ChoreoGraph’, and the first 
prototype, programmed in MAX, allowed the choreographer to drag and drop a 
series of differently coloured modules (each module representing some part 
of the whole) along a time-line making it possible to change the order of 
the piece during the performance. The first performance that used this 
prototype, Solo One, was done in 1998. Each coloured module represented a 
particular movement phrase and music sequence and the dancer could watch 
the monitors on the stage to see the arrangement the choreographer might 
select. Central to ‘ChoreoGraph’ is the concept of a ‘non-linear’ 
choreography that does not rely on the convention of a fixed time 
structure, but is open to rearrangement. After Solo One, Michael and his 
colleagues started to develop the software to arrange the order of modules 
according to computer algorithms and audience and performer sensor input. 
Each new version of ‘ChoreoGraph’ is produced in conjunction with a 
performance and implements additional functionality and explores further 
the relationship between the computer software and choreographic structure. (1)

The most recent version of ‘ChoreoGraph’ was developed with the creation of 
Duplex, a duet that premiered on the 6 and 7 March 2002 at the TAT, 
Frankfurt. William Forsythe, director of Ballett Frankfurt, provided the 
dancers, rehearsal and performance space and the marketing and development 
work that would accompany the performance premiere and tour. The 
Collaborative Arts Unit, Arts Council of England, provided additional funds 
to help to develop this version of the software. The primary team consisted 
of Michael Klien (choreography); Jone San Martin and Fabrice Mazliah 
(performers); Volkmar Klien (music); and Nick Rothwell (programming). The 
following conversation is liberally edited together by Scott deLahunta from 
a series of electronic mail exchanges we had after the second performance 
of Duplex:

Conversation:

Scott deLahunta (SD): I have a series of questions I would like to ask 
about the piece and its development, but maybe you could just describe one 
of the underlying premises for the work. You say the basic structure is the 
‘classical pas de deux’, can you explain what you mean by this?

Michael Klien (MK): The classical pas de deux consists of an entrée, an 
adage, a solo for dancer one, a solo for dancer two and a coda. I always 
thought this would provide an overall coherent structure that should 
support the development of the ideas we were aiming for with the software.

Nick Rothwell (NR): Working within this structure of the pas de deux, the 
building blocks of the piece are mediated via an algorithmic core that 
provides a real-time visual display for the dancers. It also cues and plays 
the components of themusical score, according to a set of non-linear 
constraints that formthe overall choreographic structure.

SD: Just before getting into talking too much about the software, so I’m 
clear, the two dancers are cued on stage by four monitors arranged around 
the space. All four monitor screens display the same information, which 
includes a horizontal time line for each dancer and a green ‘go’ line 
running vertically along one side of the screen. The coloured modules 
appear on one side of the screen and move slowly along the dancer’s time 
line taking a full minute before coming to the green line which gives 
enough time for them to see what is meant to happen next and prepare to 
perform the set material associated with that particular colour module.

MK: Yes, that’s exactly right. Forsythe has already established a precedent 
of his dancers taking cues from on stage monitors, and this is also 
something we tested in Solo One, so we knew the cuing system would work. 
Still, we had limited time to run through the full piece before the 
premiere, and so the dancers found it a bit difficult on the first night, I 
think dealing with the monitors and remembering all the different material, 
but by the second night there was already a vast improvement in the 
performance.

SD: And each performance is different because you use this software that 
can render a different ordering or sequence for this duet. But you can 
render new sequences without actually performing them right? Just hit 'go' 
and watch the way it permutes a different structure each time.

MK: Absolutely correct. This allowed us to test the software to see if we 
had the right 'mix' of elements set in the right proportionality to each 
other. So as Nick can attest to, I rendered lots of versions without the 
dancers to figure out the right mix. This was founded on a purely 
subjective understanding of what I wanted Duplex to be. Basically it 
consisted of five module types (individual material, shared material, 
supported material, lifts, pauses). I wanted to generate the right 
proportionality of these module types to ensure a sufficient amount of 
unison, but not too much, the right amount of canon, and so on.

SD: I want to ask Nick in a moment, as the programmer, to explain some of 
how this is achieved in the software, but first just to ask something else 
about the movement. The software does not come up with the actual movement 
vocabulary or the short fragments or phrases, but permutes different 
arrangements from the level of the short phrases (represented in these 
modules) outwards to the larger overall structure of the duet. I assume 
Michael in collaboration with the dancers came up with the movement 
vocabulary or phrases.

MK: Yes. I choreographed those sequences in a very dictatorial way. There 
are three sequences that are actually improvisation tasks and are not fixed 
choreographies. And then the dancers have the opportunity to manipulate 
certain modules in certain ways; such as repetition, loops, scaling, etc. 
In the future, I would like to bring out Duplex 2  whereby all modules 
would be pure improvisation tasks, no more fixed movement. For this version 
of Duplex one I wanted very much formalised movement and have it 
manipulated within.

SD: So, going back to the software, would you say the programme 
‘understands’ something about the structural parameters of a good duet, so 
that each iteration, while different from the last, still succeeds as a 
piece? So, Michael, besides making the movement material that appears in 
each module, as choreographer your work was to define these structural 
parameters (based somewhat on the classical pas de deux) to Nick so he 
could write the code for this version of ‘ChoreoGraph’. Is this more or 
less correct? If so, then this is a very interesting conceptual aspect... 
embedding choreographic ideas into the software and getting it to permute a 
'well made' dance every time.

MK: True. Though 'well-made' dance is questionable. I think of it more as 
generating a consistent ‘map’ for the dancers within which they make their 
own piece much more than in a traditional set-up. This becomes even more so 
when more of the modules are not set, but are more openly improvised. But 
it's also true that I would like to continue research in the way you are 
describing as well, to create what I would call  'choreographic templates' 
which anyone can fill in (can be literally anyone  from my mom to Baryshnikov).

SD: Would it not be possible to create new movement vocabulary and a new 
set of 36 phrases (the number of different phrases/ modules made for 
Duplex) and use the software to permute different orderings of these? Would 
another choreographer challenged to make new movement vocabulary and 
phrases for the Duplex version of the software also be able to create a 
'good' dance or consistent map or was there something integral to the 
design of the software that predisposes it to being used successfully only 
with the movement material Michael and dancers made? (Although Michael I 
seem to recall you said once to me that the actual movements don't matter 
so much in this context?)

MK: I actually changed my mind on that (I guess it was me who said such 
things). I think for Duplex this particular movement material is important. 
However, maybe that doesn't mean that it wouldn't work otherwise as a 
‘choreographic template’. I guess maybe it would. It would be a bit crude, 
but I think it would work in an educational setting for example. Yes, you 
could also just do 10 phrases or modules or you could do more...the 
parameters are quite easy to tweak.

SD: What do you mean when you say "the parameters are quite easy to tweak"? 
Can you say which parameters and if the tweaking is what you do or Nick or 
both?

NR: Maybe I can respond to that. The parameters Michael refers to are the 
assigned "weight" values of the various movement modules, the refresh 
settings (which prevent a particular movement module or chain of modules 
from repeating too regularly or too often), and the various graphs of 
weight parameters over time. These would be fairly easy to adjust to fit 
another type of structure.

SD: But I assume Nick this means you would have to come along with the 
software to make these changes? At least until you manage to build a 
user-friendly interface, which I suppose is the aim with your recent 
application to NESTA (National Endowment for Science, Technology and the 
Arts). But before getting into a discussion about the future of 

‘ChoreoGraph’, I want to return to my questions to Nick regarding the 
software. Is there any way that Volkmar or Nick could explain in 
computational, but hopefully accessible terms what the mechanisms are for 
this right ‘mix’ that Michael refers to. How does the software determine 
‘proportionality’? I have something in mind about dynamic curves that 
someone mentioned?

NR: The ‘ChoreoGraph’ (at least for Duplex) is a reasonably clean rendering 
engine (which finds out what it needs to know about module classes, types 
and weights from a configuration file) attached to a collection of 
custom-crafted rules written as MAX sub-patches. The custom rules dealt 
with (for example) placing the purple section in the second solo and with 
ending the entire piece with the white unison. Pretty much everything else 
is generic, including the following of the curves and weights for the 
sections. The resulting shape of the piece is a combination of a properly 
configured generic engine plus some custom linkage.

SD: I'm curious if there is an area or field of computer science research 
that the algorithms you are using are particularly connected to, e.g. 
probability and random processes, detection and estimation, databases, 
numerical computation, etc.?

NR: The computer science employed is fairly simple, amounting to little 
more than linear programming for the most part, with some machinery for 
probabilistic spread and fairness when doing the module selection.

SD: Thanks, I would have no idea how to implement it in code, but what you 
say makes sense to me. Can I ask about something else Nick told me last 
autumn about the aim to programme the software so that it would store or 
remember each permutation of Duplex so it could ‘learn’ from previous 
versions. In this way, each new performance of the piece would retain the 
best results from the previous performances. And how would this compare to 
genetic algorithmic projects where the evolution of plants or something is 
based on a process where each generation is informed by an evaluation and 
selection from the previous one?

MK: Wouldn't that be lovely! I think we are working on it. Duplex had a few 
aims we had to accept as too ambitious at this point. We have, however, 
started to use some of the history to feed forward. The feeding forward is 
not the problem, to make the feeding forward meaningful is. Duplex is also 
far too limited to make a future based on its history fed forward in a 
wider sense as it has no ‘metabolism’ nor does it create offspring. This is 
where Einem comes in which is the next solo and version of the software we 
are working on. This one should work with a clear metabolism. Maybe we'll 
manage to code in some sort of genetic algorithm for it to create 
offspring, though I actually think that we will take a few years for the 
latter (you might see it in Cellfish). The algorithmic side is not the main 
(although it is difficult) problem. The primary concern is to find a 
mechanism that is meaningful as an interface for a performance that works 
together with the dancer and is not just 'isolated' in a virtual world (as 
most of the A-life stuff is).

SD: This seems the challenging part to communicate to people -- there are 
many things going on here at once. It seems you are in the process of 
generating choreographic structures in two contexts and in fact the 
software structures are just as important, but they are invisible to the 
audience. What intrigues me is the relationship between these invisible 
computation structures and the dance. I don't think I would refer to A-Life 
as 'isolated' in a virtual world. The aim of experimenting with cellular 
automata, for example, is to learn from the examination of the relationship 
between rules and contexts and emergent behaviour. Would you not be doing 
the same thing with ‘ChoreoGraph’, using it to examine and learn about 
dance structures.

MK: Well, the main thing is that we are not contributing to a scientific 
discussion with our work. We do not want to model anything separately in 
the virtual world. Maybe a quote from Gregory Bateson [Steps to an Ecology 
of Mind] will help explain what I mean. “It would be incorrect to say that 
the main business of the computer, the transformation of input differences 
into output differences, is a mental process. The computer is only the arc 
of a largercircuit that always includes a man and an environment from which 
information is received and upon which efferent messages from the computer 
have effect. This total system, or ensemble, may legitimately be said to 
show mental characteristics. It operates by trial and error and has 
creative character.” I don't know if that makes sense, but what I want to 
outline is that we are working in designing the 'whole' arc and that any 
part of the system makes no full sense. So, I don’t see that we are 
generating structures in two contexts as you suggest, although maybe parts 
make sense in certain applications. I would have to think about that.

SD: Well, the quote from Bateson helps to demonstrate how you are framing 
the project for yourself, but I still find myself drawn to the idea that 
the choreography can exist simultaneously and externally in these two sites 
for abstraction and artificiality -- the algorithm and the stage. And I’m 
curious where and how the audience gets to perceive the algorithm? If we 
are thinking in continuities and cybernetic systems that include the 
dancers, the software and the viewer, then it makes sense to me, but for 
some reason I always find myself separating components of such systems out. 
I think it's a sort of test for relevancy or importance/ value or something 
like that. In other words, without the software, the choreography 
(choreographer), the dancers, (the theatre space), the audience already 
form a sort of cultural/ social system. You are adding the software and 
those who are involved in its development into this system as a major 
contributing component, but the viewer can enter into a debate of whether 
or not the technology makes a 'difference' because it's invisible or not 
perceivable.

NR: Actually, I think it is perceivable by the audience, but obliquely: 
we're trying to present work with an unorthodox creation method exactly as 
if it were created in an orthodox manner. It becomes something of a 
meta-game between creator(s) and audience, where the imagery and emotive 
projection onto the piece by the audience are the pieces of the game.

MK: I also think, and that is where people can disagree, that the whole 
system makes a huge difference on stage in a very small way. I think that 
it becomes perceivable that the dancer is put in a state where she or he 
has to build strategies, be creative and find solutions beyond physicality. 
It's a process that allows the dancer's mind to be 'choreographed' and not 
just the body. I think that Duplex displays this subtle and for me 
beautiful and exciting quality of play, risk and non-verbal communication 
not commonly encountered in formal dance pieces (that are not 
improvisations). I also am stimulated by the layer of knowledge that any 
manifestation is only a manifestation of Duplex...you can never see Duplex 
as such, only manifestations. It's also about coexistence and dependence 
(whereas the computer doesn't really care if the dancers are dancing to it 
or not - but I guess Nick does).

SD: I can see where the unorthodoxy and interdependence overlap. I am 
trying to find a way of reflecting on the relationship between the 
conception, intention and realisation of the project that accurately 
accounts for this relationship between the software and the choreography 
(and your collaboration). I haven't found the right words yet, but the 
project seems to resolve into some combination of Michael's systematic 
descriptions of choreographic structure (and creation of movement 
vocabulary), Nick's ability to code these systematics into workable 
algorithms and do the cuing interface in MAX, Volkmar's contributions to 
the music (and the interface?) and the dancers' ability to work in this 
particular mode.

MK: Actually, initially the whole idea came from the need to get music and 
dance (and other media) somehow synchronised - even if both work in a 
'non-linear' fashion. The music side is mostly completely underrepresented 
in discussing this system (as Volkmar talks less than me) - it's a quite 
amazing element of the whole thing. Volkmar, could you please elaborate?

Volkmar Klien (VK): I agree, it is all very complex indeed.

SD: Thanks Volkmar. Okay, but one more thing about this separateness. To 
what extent could you see the software as an autonomous art work or 
documentation. It is, after all, coded to contain and interactively display 
a choreographic structure and is functionally aestheticized (green line, 
black screen and brightly coloured modules). You hit the go key and you get 
a new dance sequence each time. What prevents its inclusion into the canon 
of dance for screen or dance sketches/ notation for example.

MK: Well, the way I see it is that “yes” the system can stand-alone, but I 
would compare it more to a computer lighting board at this stage. If you 
are a lighting designer you can take programmed cues and just watch them as 
numbers on a monitor and it will tell you something, as the lighting 
designer you will be able to visualise the performance. For everyone else, 
it's just numbers on a screen. So the ‘ChoreoGraph’ in its current form is 
colourful squares on a screen, meaningful to some and useless to others. It 
is an 'interface' for performance. As a stand-alone it doesn't make sense 
at the moment and I am not sure it ever will. This current version is 
obviously fully integrated into Duplex. Perhaps in the future with proper 
funding certain autonomous software elements or stand-alone wholes will be 
developed.

SD: Are you planning to let other choreographers work with it in some way?

MK: Yes - whenever they want - we all think it would be great. The main 
problem is to make it user-friendly enough. If we get the NESTA funding 
then in about eighteen months we would hope to have a downloadable 
documented version from http://www.choreograph.net.

SD: Speaking of future developments, Nick, you mentioned that both Nodding 
Dog and Duplex have lots of unique lines of code in them and that 
essentially makes them separate software packages with little that is 
generalised in the systems now. Does this mean the next time you create a 
work of 'non-linear' choreography you will have to start over again with 
the code even though the basic ideas behind ‘ChoreoGraph’ remain consistent 
from one project to the other?

NR: Yes, essentially it does mean that one has to start coding each project 
from scratch.

MK: I think we are learning as we go along - they might have different code 
in them - both though have similar interfaces. It teaches us about 
applications - and how to achieve certain things.

SD: But where and when do you expect to become more generalised about the 
underlying software architecture? I suppose this is something you would 
hope to achieve with NESTA funding (which is for quite a substantial amount 
of money).

NR: Yes, I see NESTA as a potential resource to move ‘ChoreoGraph’ from the 
specific, bespoke applications (such as Nodding Dog and Duplex) into a 
generic platform, so that new projects/ applications have a much lower 
barrier-to-entry. Of course, it is not totally clear exactly when is a good 
time to go from the specific to the general. It's an engineering trade-off. 
If we stay specific it is much more work, but we don't close down new 
approaches and creative processes, where a general tool might do so. My 
feeling is that we need another couple of bespoke projects before we have a 
clear view of the application space. But obviously we are still going 
through with the NESTA application at this point.

SD: Okay, you have already made mention of the three previous projects, 
Solo One, Nodding Dog and Duplex and two coming up, Einem and Cellfish. 
Each has built on knowledge gained from previous versions of ‘ChoreoGraph’ 
[see versions of ‘ChoreoGraph’ performances described below]. What emerges 
here is not any single piece, but the image of a series of works in which a 
form of and approach to a relationship between code and choreography is 
being developed.

MK: Yes, each new piece teaches us different things and allows us to create 
different aspects of a 'non-linear performance software engine'. Solo One 
about the basics; Prosxima's Drift (without computer) about time-rule 
grids, dynamic curves and carrying the past forth; Nodding Dog about 
interfacing with and working out complex choreographic systems; Duplex 
about everything else (formalising choreographic structure, the notion of 
'maps for dancers'). But it’s important to remember that the choreographic 
strategies have to be developed as well as the computer aspects. To make 
successful pieces in this 'non-linear' manner we have to develop 
choreographic techniques, compositional techniques and the code 
simultaneously and with each aspect taking approximately the same amount of 
time.

In the future, as I mentioned, we will concentrate on other aspects such as 
metabolism, growth, homeostasis, reproduction and adaptability some of 
which will be addressed in Einem and some later in Cellfish. Nick should 
elaborate on some of this. But what we hope to do is to get some 
substantial support and have the chance to take a much larger development 
step, towards the generic platform Nick mentioned and also to make it more 
accessible for others to work with. We started on the project in 1997 and 
have, with the help of several organisations to whom we are very grateful, 
been able to develop each prototype version performance by performance. (2) 
While we will continue to do this and are currently in negotiation with the 
Tanzquatier, Vienna and ZKM, Karlsruhe to co-produce Einem with us, we have 
our fingers crossed for the NESTA application.

SD: Well, I wish you luck with it and look forward to seeing the next 
version of ‘ChoreoGraph’.

END/ END/ END/ END

A list of previous and future versions of ‘ChoreoGraph’ (by Michael Klien):

1) Solo One (London 1998)
This solo aimed to demonstrate the very basic concepts of non-linear 
choreography or the idea that elements of a choreographic structure can be 
put in algorithmic relation to each other and altered/ manipulated in real 
time (via various inputs or algorithms). This solo was also the first time 
that we  used monitors to cue the dancers tasks.

1b) PDE (London 1999)
Building on the basic ideas of Solo One and incorporating them in a piece 
of 'public art' PDE was created as a ‘peripheral’ performance piece using 
the 'ChoreoGraph' software to create a marginal, seamless, endless and 
comforting performance piece, that adapts instantly to the atmosphere of 
the location and supports it. Various sensors collect data in the location. 
This information is fed into the computer, which arranges the 
movement-script and music according to dynamic levels to suit the 
environment. The dancer is updated via a monitor in 'real-time' 
(instantly). PDE is aimed at public spaces (i.e., foyers, restaurants, bars 
and cafes) and is a reference to 'wallpaper-art'.

1c) Cay - Portobello Festival/ICA (London 2000)
This piece represented our first attempt to incorporate non-linear 
elements, as well as the developed software of Solo One, in a mid-scale 
performance setting. Two adapted and extended versions of Solo One were 
used to influence (and were influenced by) a third, more theatrical, 
performance that worked along a linear-setting. The two versions of Solo 
One were connected via close-circuit telematics; a side-feature used to 
connect two spatially separated stages via video. We've been looking into 
distributed control methods, which are regulated and processed via the use 
of a base-structure.

2a) Prosxima's Drift (Athens 2001)
Thematically this piece deals with flow. Practically as well as 
conceptually this represented us withthe challenge to create 'flow' via the 
use of a rule-based choreographic method. The 'ChoreoGraph' software was 
NOT used for generating/ creating structure or scripts. Rules (individual 
rules and group rules including movement, timing, spatial, dynamics, etc.) 
were executed directly by the dancers themselves, according to their own 
personal assessment of the current overall state of the piece. The overall 
dynamic structure of the piece is laid out via the use wave-dynamics 
coupled with the current moon-illumination on the time and date of the 
performance. This ensures a perpetual novelty in the piece's sub-structure 
(out of the dancer's control) on top of which other rules are applied. The 
final manifestation on stage is not dissimilar to computer-based cellular 
automata when intelligent beings (dancers) judge the 'state' of the piece 
to conclude (find a strategy) with which to execute certain rules. 
Choreographically it was also a research project into 'play on stage', 
carrying forward dynamic curves in time (the past conditioning the future)

2b) Samen (Vienna 2001)
A solo by Davide Terlingo that explored the notion of non-linear 
choreography further forming something like a bridge between Prosxima's 
Drift and Nodding Dog in choreographic method.

3) Nodding Dog (Vienna 2001)
A piece based on complexity, non-linearity and interdependence. Nodding Dog 
acts as one large adaptive system, composed from a number of dynamic 
choreographic sub-systems (structures that work as an entity by itself, but 
are effected by other entities and form subroutines for meta-entities) that 
stand in constant inter-play with each other. We have been looking into how 
the computer can act as a not too complex 'regulator' on stage, taking 
various inputs to insure synchronised media (lights/live-music/dance/film). 
So here we have used a clear and developed choreographic method inspired by 
system theory, game theory and cellular automata. This choreographic method 
allows the piece to be regulated by a simple device (such as the 
'ChoreoGraph' ) in a simple way to achieve a clear change. (ie: The screen 
informs all 'players' that a subsystem is closing and other are opening) 
without a necessarily predefined order.

4) Duplex (Ballett Frankfurt, 2002)
Duplex has clearly been the most developed 'symbiosis' of software and 
choreographic method. The software was used to display a rather clear and 
in itself logical 'map' of the piece (a sort of notation of the piece). The 
dancers then could, with the help of and according to certain choreographic 
devices, interpret the map; read it, stick to it, ignore it, interpret it, etc.

5) Einem (ZKM/TQW 2002)
In Einem we are aiming to develop a structure that possesses a kind of 
'information metabolism' . Hence, the work will have the potential to carry 
a) the past forward and b) to change over time. This will be achieved by 
letting the dancer interact and nurture the structure throughout the 
'life-time' of Einem. There are various points that have to be addressed; 
choreographically, musically, and programming. We will be concerned 
specifically with Gregory Bateson’s theories concerning “when a difference 
is a difference”and how is an individual conditioned by his or her past? I 
think we'll probably need another versions of this work to address 
questions of learning, homeostasis and adaptability in choreographic 
structures.

6) Cellfish (2003/04)
This piece proposes choreography as the generalised genotype of a dance 
(GTYPE), with performances being its generalized phenotype (PTYPE). Similar 
to A-Life, in which the generalised genotype stands for any collection of 
low level rules and generalised phenotype for the structure and/or 
behaviour that results when those rules are activated in some specific 
environment. The piece itself will be an adaptive structure that will 
develop and 'learn' through the experience it gathers during its 
'lifetime'. A piece that collects all the research results of the previous 
pieces to create something like an organic structure with the added element 
of genetically encoded information for future use.

6b) Cellfish 2 (2004)
A variation on Cellfish

7) Collider(2005)
Cellfish and Cellfish 2 meet and produce a new piece.


ENDNOTES:

[1] The ‘ChoreoGraph’ project has several precedents in the history of 
research into regulatory systems, both in the field of computer science 
research as well as in the arts in the areas of music composition, painting 
and architecture. In the dance field one of the precedents is the work of 
John Lansdown, an architect by training. Based in London, Lansdown was 
particularly interested in the possibilities for ‘artificial creativity’, 
and, in 1968, he began to experiment for the first time with ‘computer 
generated’ dances. For reference: John Lansdown. “Computer-Generated 
Choreography Revisited”. in Proceedings of 4D Dynamics Conference. ed. A. 
Robertson. De Montfort University, Leicester, 1995. pp. 89-99. Available at 
URL: http://www.dmu.ac.uk/ln/4dd/guest-jl.html.

[2] The project has been supported in the past by: London Arts Board (1997 
and 2000-2001); Arts and Technology Centre, London (1998); Greenwich Dance 
Agency, London (1998); Collaborative Arts Unit, Arts Council of England 
(2000-2001); Tanzquatier Wien (2001); Ballett Frankfurt (2001-2002); and 
deserving special mention are the following individuals: Samantha Jones, 
Dean Xavier, Nik Haffner, Bronac Ferran and William Forsythe.

++++++++

For more information on Barriedale Operahouse and its member artists go to: 
http://www.barriedale-operahouse.com/duplex

Scott deLahunta does research, writing, speaking and consultation work 
related to the impact of new media and information technologies on live 
performance arts practice with a particular focus on dance. For more of his 
writings and reports go to: http://huizen.dds.nl/~sdela/

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net