SOFTWARE   FOR   DANCERS:   THE   USER'S   GUIDE   back to main page

software for dancers: coding forms

ABSTRACT:

This essay engages with the question "what is software?" as a reflection on and extension of the Software for Dancers research project based in London in Autumn 2001. This project brought together a research team comprising four established contemporary choreographers and four digital artists to develop concepts for a software rehearsal tool(s) for choreographers. As one of the outcomes of the project, this essay aims to contribute to a growing area of study of software as a condition and shaper of cognition, creativity and culture. It defines and seeks interrelations between aspects of software arranged under three headings: software as a language; as a tool; and as a material. Through this engagement with the topic of software, the essay attempts to transform the computer into an invention open to critical reflection and less a product upon which society has come to rely.

by Scott deLahunta, 8/01/02

Draft version of essay submitted to the Journal of Performance Research, Translations Issue

An Introduction

In January 1967, A. Michael Noll, one of the first computer scientist/ artists to explore and espouse the convergence between computers and art, wrote an article in Dance Magazine entitled Choreography and Computers, in which he described a software program he was creating that would indicate stage positions of stick figures and could potentially be of use to choreographers. In the same issue, Ann Hutchinson-Guest (an authority on dance notation) wrote A Reply to A. Michael Noll's speculations, in which she writes that the computer will 'never replace' the facility a choreographer has for composing movement with the dancer. However, she does concede that the computer might assist in the overall outlining and editing of a score for a dance (Noll and Hutchinson 1967).

While the debate started by A. Michael Noll and Ann Hutchinson could still be considered relevant today, three decades later our perceptions of computers and dancing have both changed; generally not along the same trajectories. The cultural environments incubating contemporary dance since the 1960s, largely the United States and Western Europe, have also been the factories for the enormous production of cultural fact and myth as related to emerging technologies. Obviously, the computer has not replaced the choreographer, nor did it ever really threaten to do so, but the ways in which it has evolved to influence how we think, communicate and interact suggest that it would be a fruitful time to revisit the question of how might a software program be of use to a choreographer.

The Software for Dancers research project that took place in the autumn of 2001 in London was conceived as an opportunity to update the 1967 debate. (1) The main research team comprised four established contemporary choreographers and four digital artists, three of whom had experience with dance. The digital artists came with a high level of skill with sound and image editing software tools as well as a range of experience with programming and scripting. In other words, as a part of their digital arts practice, they had the ability to customize or create their own software - thus aligning them with the notion of 'coding' as creative practice. The shared central task of the group would be to develop concepts for a software rehearsal tool(s) for choreographers. This provided the stimulus to explore shared and divergent approaches amongst the participants across a range of ideas related to the recognition and transformation of structures and materials in the process of art making, whether computational or choreographic. Some of these explorations were made more explicit through dialogue while some evolved as tacit frameworks within which other discussions took place. One of these inquiries, while never overtly exposed, repeatedly nudged itself close to the centre of our talks, and it is to that question, 'what is software?' that I devote the remainder of this essay.

These are relatively early days of the impact of software as a cultural force and the bulk of its study still resides in the fields of computer science, engineering and mathematics with rapidly increasing dissemination throughout the biological sciences - a field computation is poised to revolutionise. The question 'what is software?' within these fields will initiate a very different response than when asked within an arts and humanities context, where it is essential that frameworks for exploring software and its implications are further developed. Software for Dancers provides a modest but significant context for contributing to this discourse by investigating what software is under the following headings: software as a language; as a tool; as a material.

As a Language

Computer programming relies on the use of artificial languages, e.g. C, Fortran, Pascal, C++, Java, etc. These languages follow a strict formal schema; they have a precise syntax and vocabulary that leave little room for the forms of semantic and interpretive slippage we are accustomed to with the natural languages such as English or Spanish. (2) The computer will always interpret an instruction (or algorithm) written in a computer programming language in exactly the same way every time. These instructions often come in blocks of code created by someone else and are assembled, more a building structure than something written. (3) If we accept that any symbolic systems of expression we gain knowledge of, such as a natural language, shapes a way of thinking, then learning and using a computer language could have the same effect. These artificial languages bear enough similarities to natural languages that it could be said that anyone can learn to program a computer. As more computer languages are invented to choose from it seems possible that an increasing proportion of people will find themselves writing and thinking in code.

Computer languages are said to have evolved through several generations, the first of which was 'machine code' that spoke directly to the computer's microprocessor using strings of 0s and 1s. Following machine code, there came a second and third generation of computer languages each making the task of coding easier to learn and perform. Third generation languages are significant for having developed a set of standards that enabled programs to run on a greater variety of computers because the syntax of the language is 'in principle independent from the computer they run on' (Economist 2001). Beyond a certain point any discussion of computer languages in generational terms is misleading because it implies a steady development from one generation to the next, which is not the case (Miller 2000). Although the trend has been towards creating programming languages that are ostensibly easier to learn and use, there is more to consider than simply skills acquisition. A coder chooses a language both for what it can do (some languages are designed to perform certain functions better than others, e.g. Perl is considered by some the choice for Computer Graphics) as well as how it allows one to think through the coding process (Sol 2001).

Certain developments in programming languages can be viewed as influencing and influenced by cultural shifts in our understandings and uses of computation. 'Object oriented' programming (OOP) began to evolve in the late 1980s. OOP favours the modelling of real world entities in computer code and is designed to simplify and streamline programming. Previously, computing languages kept functions (code) and structures (data) formally disconnected. In OOP, software objects operate as sealed combinations of data and code, and the sending and receiving of 'messages' conducts communication between them (Montlick 2001). This, according to sociologist and computer scientist Alan Shapiro, represents a fundamental change in the field of computer science. In his essay, Society of the Instance, Shapiro writes that 'beyond a certain (im-precise) point in time, without realizing it, object-orientation definitively transgressed the limits of the discrete, binary, nominalist, symbolic logic which was the "original" foundation of computing' (Shapiro 2001). Others have made similar observations. Philosopher Brian Rotman, in an essay on the relationship between serialism and parallelism, also positions OOP as one of the signs of the shift to a post von Neumann conception of the computer. He posits that the rise of object-oriented programming counter poses 'the linear flow of procedural programming languages by foregrounding the manipulation of (…) available objects' (Rotman 2000).

Shapiro's essay is a critique of OOP on the grounds that it is another symptom of the increasing tendency to provide 'substitutes for human experience', while Rotman induces from several developments a cultural trend towards a 'collectivised, distributed, pluralized' intelligence, of which OOP is one example. Both positions contribute to a growing area of critical discourse as regards the evolution of software as a condition and shaper of culture. Others go further as in the case of respected media theorist Friedrich Kittler who proposes that the acquisition of an artificial language should be as important as learning a natural language:

I can't imagine that students today would learn only to read and write using the twenty-six letters of the alphabet. They should at least know some arithmetic, the integral function, the sine function - everything about signs and functions. (…) Then they'll be able to say something about what 'culture' is at the moment (Griffin and Herrmann 1996: 740).

Kittler's emphasis on the sort of schooling required to understand software can be debated (maybe it isn't necessary to learn the sine function), but not the importance of implanting in more students/ people a broader appreciation of what software is and its implications for culture. It is necessary to find ways to shift this study from its current science, engineering and biology base towards the arts and humanities. A. Michael Noll's computer in 1967 symbolised an entirely different entity that the computer in 2000 - and the evolution of computer languages is one of the reasons why.

As a Tool

In terms of current cultural perception, software is probably more commonly conceived of as a tool, or part of a tool set that includes the computer, than as a language. In this discourse, the tool-ness of a piece of software is embedded in the assumption that the software has a purpose. The purpose of a hammer is to drive a nail (amongst other things). The purpose of a calculator is to perform calculations. The purpose of iMovie (a software program that now comes bundled with every Apple computer) is to edit digital video.

In the industry, the top-down process of 'software development', begins after the 'purpose' of the software, what the client or customer wants it to do, is thoroughly understood and articulated. In this process the purpose tends to be defined by the recognition and specification of the overall 'problem'. This problem then goes through a process of further analysis to break it down into smaller pieces. Once this is accomplished, the next step in the procedure is to devise the solutions for the problem(s) in the form of algorithms or instructions to the computer. Once the algorithms are defined, then they are implemented in some form of software language. There are other systems or software environments that encourage a more 'bottom-up' approach to programming. One of these would be Max, a high level graphic programming language geared specifically to real-time computer music applications, where it's possible that the individual coder may employ a much more experimental approach in which 'immediacy, serendipity and play' are explored, coding in such a way that one choice leads to another with unexpected results (Winkler 1999: 73).

The Software for Dancers discussions didn't employ either the top-down or bottom-up process, consistently, but borrowed from each. Because we had agreed to develop concepts for a screen based software rehearsal tool and we were working together across a range of different approaches, the discussions were initially dominated by top-down procedures that generated questions such as - what do we want the software to do… what would its purpose be? What problems could we come up with that a piece of software could solve? Alongside this, we worked through a process of selection and elimination of various possibilities. We established some additional parameters at the outset such as the software should run on a standard (off the shelf) portable computer with only mouse, keyboard and audio video input. The consensus was that we were investigating the possibilities for some sort of digital 'choreography sketchbook' and that we would rigorously explore what could be done with two-dimensional representations (although vector based 'pseudo 3-D' was discussed). This eliminated from further discussion the creation of software that would model the real world (objects, space and human figures) in three dimensions. (4)

Paradoxically, during the Software for Dancers discussions, simultaneous with any linear progress made towards developing concepts for a software tool for a choreographer, an impulse away from the fulfilment of this particular objective would be expressed. In one breath, someone would identify a potential use for a certain software application in the dance studio; in the next moment this would be negated by arguments both pragmatic (e.g. the problem was solvable in a more efficient way) and artistic (e.g. fundamental formal contradictions could be named). The software as a tool for the making of dances also became the object around which a balance between the technophobe and the technophile in each of us was maintained. In another contradictory setting, both the choreographers and the coders agreed that what they would like to be able to do is to 'abuse the software' and to get 'beyond the tool', while at the same time it was apparent that no software was going to be coded until there was some consensus on the function it would serve - its tool-ness.

Transcending and abusing the software as tool returns us to the consideration of software as a language - for to enact either requires access to and knowledge of the code - and to the cultural meanings of software. I have already pointed out that software as a language differs from natural languages due to its strict formalisms and precise syntax. Software as a tool, developed for a particular purpose, further expands this separation between artificial and natural languages. For example, two different programs may be coded to serve the same purpose. So, syntactically they will differ, but semantically they might be considered to be the same, a separability that does not occur in the natural languages. Philosopher Peter Suber in his article What is Software?; asserts that the intended use of software tends to shift its meaning entirely from the 'uninterrupted arrays of bits to the function computed or the output and operation as interpreted by human beings. We look to the uses of the program to the programmer or user, not to the structure that permits it to serve those uses' (Suber 1988).

Seen from this perspective, the labour of the software programmer is rendered into a form of invisibility; with the code unseen the software becomes a tool, an implementation device for the end user alone. Perhaps not the most compelling argument to support Kittler's view that everyone should learn an artificial language - if through its use the writer never actually speaks directly to the reader. Or, it is one of the most compelling arguments to support the need for some form of software literacy that perhaps does not provide reward for the individual coder in the shape of a 'reader' nor requires everyone to learn to program a calculator in Visual Basic (a basic exercise in learning to use this object oriented program built specifically for Windows environments). This other form of software literacy might emphasise access to a discourse that contextualises these products and processes of culture in such a way that we better understand our complicated relationship with computers.

As a Material

The use of computers in art can be traced to computer graphics experiments in the 1950s. In the 1960s and 70s, before the arrival of the personal computer, the conception of the computer as a creative instrument or tool promoted the view that artists should be working together with scientists and engineers from within whose domain the art-useful computing discoveries were being made. During this period, two early computer researchers, A. Michael Noll and John Lansdown, both showed a particular commitment to the integration of choreography and computers. As already mentioned, Noll was working on a computer program that would provide a graphical notation aid to the choreographer, and Lansdown, an architect by training, was especially interested in the use of the computer to provide creative input through the algorithmic generation of choreographic scores (Lansdown 1978).

The creative use of the computer underwent radical transformation in the 1980s and 90s, following the major developments in technology as partially marked by the headings with which we are all familiar, e.g. the emergence of the personal computer and graphical user interface, the internet and world wide web, etc. During this time, art making involving digital technologies gave rise to different branches of computer art, e.g. digital art, interactive media art, telematic and net art, etc. The particular conditions that supported the collaborative interests of artists and computer scientists in the 1960s changed, as there became easier access to hardware and software. During the 80s and 90s, artists were developing the ability to customize or create their own software. Programming languages became easier to learn and use and image, video and sound manipulation software tools became widespread. However, despite artists gaining more control over the software code, the perception of software in the context of art making still remained largely a function of its purpose.

Recently a discussion of an 'art of which the material is software' has begun to take shape, marked by the Software Art award category newly established in 2001 at the transmediale.01 art festival in Berlin, Germany.

This competition recognises the artistic work done by hybrid artist-programmers who are neither 'interactive media artists' or 'net artists', but whose aesthetic material is code and whose expressive form is software programming. The definition that has been suggested for Software Art is that it incorporates projects in which self-written algorithmic computer software (stand alone programmes or script-based applications) is not merely a functional tool, but is itself an artistic creation (Broekmann 2001).

The naming of 'categories' for emergent arts practice is always contentious, but whether this concept of software as a material is new is not the discussion I am interested in opening up here. The point is that since the 1960s, our perception of software, its surfaces and interiors is reflected back to us from many sources, especially our screens, and the Software Art prize has taken note of this. To quote Florian Kramer and Ulrike Gabriel reporting on the Software Art award, 'Thirty years later, after personal computing became ubiquitous, cultural stereotypes of what software is have solidified' (Kramer and Gabriel 2001). Both of the awardees for the transmediale.01 Software Art prize had created software that played with the conventionality of certain user interfaces through parody and disruption. This approach isn't new, and their software pieces sit alongside a history of art works aiming at and subverting social stereotypes using various media materials, e.g. video, radio, etc. But the award does seem to mark the first recognition of software specifically as a material in this context.

Perhaps to consider software as a material reflects less on categories of practice than on the pressing need to recast software in ways that are 'at least relevant to our individual styles of thought'. These are the words of John Maeda, computer programmer and graphic artist whose recently published book on digital design, Maeda & Media, demonstrates the creative and intellectual latitude that comes into play when software is treated as material. Maeda is the director of the Aesthetics and Computation Group at MIT's Media Lab and a leader in the field of integrating computation and visual design and in developing software as an art medium. (5) Maeda is committed to liberating the computer as a 'truly plastic medium' to counter current society's tendency to produce 'two distinct types of thinkers: one who is technically adept and humanistically inept, the other who is humanistically adept and technically inept' (Maeda 2000: 439). For Maeda, for whom visual design is paramount, the fact that the underlying code is rendered invisible is offset by his belief that the creating in code (as opposed to conventional design instruments) contributes to a fundamental reshaping of cognition. Perhaps the materiality software has to offer then is not in the classic sense of a material seeking to have form imposed upon it or in works seeking to expose software stereotypes, but the manner in which it forces the creative thinking process into an double externalisation of itself / firstly the code and secondly its execution.

A Brief Summary

It would seem that the exponential advances in digital technology would have rendered possible some of the aims of those early explorations into the use of computers in dance. Thirty plus years of cultural assimilation has also created a willingness on the part of the dance field to consider the input of computers anew. In fact, a handful of software concepts did emerge from the Software for Dancers project, and these are being proposed for further development. (6) However, equally interesting was that a certain line of questioning could transform the computer (especially that Apple G4 titanium notebook) from a sleek object of desire into a manifestation of creative ideas, a process of invention open to critical consideration and the seeking of insights that could reflect upon both computation and choreography.

As mentioned, software provided one of the ways into the discussion, but my examination here of the question 'what is software?' reveals an inquiry in need of more exposition, e.g. Maeda's revival of the individual creative artist working with software is worth comparing to Brian Rotman's reading of the evolution of technology that emphasises the emergence of cognitive and collective inter-connectedness. Still, there emerged a few general points worth reiterating.

Firstly, the study within the arts and humanities of software as a condition and shaper of culture is already forming shape as can be seen in the various critical discourses as regards computer languages and software emerging from the fields of philosophy, sociology and media theory.

Secondly, software seems poised to resist this notion of being predominantly considered as a tool and move towards some more fluid balance between utility, programmability and linguistics. In this regard, the materiality of software is a compelling concept worth further development as it can place an emphasis on giving ideas shape through code, on the process where thinking, coding and form intertwine.

Scott deLahunta
December 2001

END/ END/ END

Notes:

  1. Software for Dancers was a London-based research project taking place from 24 September to 6 October 2001 which aimed to develop concepts for a software rehearsal tool(s) for dance makers and to use this opportunity to open up discussion about collaborative practices involving live performance and digital technologies. The project was organised by Writing Research Associates in collaboration with the Arts Council of England, Sadler's Wells Theatre and Random Dance Company with primary funding from the Dance Department, Arts Council of England. The primary research team comprised London based choreographers [Siohban Davies, Shobana Jeyasingh, Wayne McGregor and Ashley Page] working in collaboration with digital artists/ coders from the UK and Germany [Guy Hilton, Jo Hyde, Bruno Martelli, Adrian Ward and Christian Ziegler] and two researchers/ writers [Sanjoy Roy and Saul Albert]. The project was facilitated by Scott deLahunta. A website with information about the project is at http://huizen.dds.nl/~sdela/sfd


  2. This reference to 'natural' languages should not be confused with Natural Language Processing (NLP) which is the work being done in the field of computing science and engineering to 'design and build a computer system that will analyze, understand and generate languages that humans use naturally, so that eventually you can address your computer as though you were addressing another person.' This quote is from the NLP pages of the Microsoft Research pages http://research.microsoft.com/nlp/ [Accessed 20 December 2001].


  3. Although here I am steering away from using writing to describe programming, I would like to suggest those interested to look at the work of writer and translator John Cayley who has covered extensively the relationship between writing and programming in his own research and practice. Several essays on this topic are on his website: http://www.shadoof.net/ [Accessed 20 December 2001]..


  4. This was partly due to the complexities of coding such programs and partly to the fact that they already exist, e.g. Life Forms, a 3-D character animation software developed with significant input from choreographer Merce Cunningham.


  5. For more information visit the Aesthetics and Computation Group website at http://acg.media.mit.edu/ [Accessed 20 December 2001].


  6. There is currently some information on these proposals/ prototypes on the project website at http://huizen.dds.nl/~sdela/sfd [Accessed 20 December 2001].

References:

back to main page or to the top of this article


-- performs a clasical ballet move (v1.0-beta)
-- known issues: no hand/arm support (will be fixed in v2.0)

on dance

    do glissade;     -- do assemblé -- not yet coded

end dance

on glissade;

    do fifthposition     do plié (demi)     do degagé (my left leg)     put the weight of my body from my right leg onto my left leg     do degagé (my right leg)     return the foot of my right leg infront of the foot of my left leg     do plié (demi)

end glissade;

-- definition of fifth position on fifthposition

    put my left leg behind my right leg with distance set to 0     put the foot of my left leg facing left     put the foot of my right leg facing right -- ouch!

end fifthposition

-- a deep plié continues until both heels are off the ground on plié { depth }

    if depth is demi then

        while the heels of the feet of my legs are slightly off the ground             bend the knee of my left leg             bend the knee of my right leg         end while

    else if depth is deep then

    while the heels of the feet of my legs are very off the ground             bend the knee of my left leg             bend the knee of my right leg     end while

    end if

end plié

-- the foot should be extending straight out from the leg on degagé { whichleg }

    keep the knee of the leg which is not whichleg bent     lift whichleg with the foot of whichleg not on the ground     point the toes of the foot of whichleg towards the ground away from my body

end degagé [by Adrian Ward and Ashley Page]