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. END PART ONE
This archive was generated by hypermail 2b30 : 05/15/02