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 the musical score, according to a set of non-linear constraints that form the 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 larger circuit 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'.

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 with the 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.

[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/

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/

back to main page or to the top of this page