software choreography [part two]

From: Scott deLahunta (sdela@ahk.nl)
Date: 05/14/02


Duplex/ ChoreoGraph: in conversation with Barriedale Operahouse

PART TWO

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/ 



This archive was generated by hypermail 2b30 : 05/15/02