0x09

This is some preliminary research into Labanotation and possibilities for alternatives. I'm much more experienced in computer programming than dance or dance notation, but I do dance quite a bit and am interested in notation systems as tools for both creating and learning, and for what light they may be able to shine on my programming practice.

A Brief History of Labanotation

Rudolf Laban first laid out Labanotation in Kinetographie Laban (1928). Since then it's become one of the most widely used movement notation systems, despite the subsequent inventions of many other languages with similar purposes.

Labanotation is heavily influenced by modern European musical notation. It uses symbols distributed along a staff in chronological order to define (from Wikipedia)

• Direction of the movement
• Part of the body doing the movement
• Level of the movement
• Length of time it takes to do the movement

The staff is a vertical line that represents time running from bottom to top. The left and right sides of the staff represent the left and right sides of the body. The staff has columns on each side of it that contain different kinds of movement, so the column closest to the staff has weight transfers (ie. foot movements), and the others record gestures. The whole thing looks very much like a musical score on its side. Christian Griesback has written a good Introduction.

Criticism of Labanotation

The main criticism I've seen others level at Labanotation is its complexity. (Densities of Agreement, Scott deLahunta et al., Dance Theater Journal 21:3, p. 18)

One of the outcomes is that these notation systems [Labanotation, Benesh], while meeting these aims quite comprehensively, are themselves complex and difficult to read and write. They are interpretable and productive only after a long period of study, and then only within a limited community of "users". This time commitment is disproportionate to the practical use of the system in the context of contemporary dance.

Scoring a full dance piece can take months, and requires enlistment of notation specialists. The required time, resources, and personnel are only available to relatively few privileged groups. The difficulty of transcribing dances in Labanotation of course limits the number of dances that get transcribed, which in turn limits the utility of learning Labanotation, which in turn makes it an ever more esoteric topic. A good dance notation system would have a very low barrier to entry so that, say, folk dancers could jot down their ideas easily while retaining the complexity that would allow notation of modern dance, ballet, and video game movements.

My personal criticism goes further. While people say Labanotation can describe the full breadth of human movement, I've found no specification for describing, say, facial expressions in Labanotation. So, Labanotation and similar systems fall short when describing movement vocabularies that have more complexity than limb movements. The subjects that fall into this un-notatable category include dance forms like Butoh and potential applications of notation like motion capture, animation, and physical therapy.

It also seems to me that Labanotation has a very limited concept of time. The bar is divided into beats and each movement takes up physical space relative to its length in time. So if a 1-beat movement takes, say, 1/8th of an inch on the page, a 3-beat movement will take 3/8ths of an inch. So length of the score scales linearly with time. The problem arises if you want to juxtapose short movements with long movements: the physical length of the score will be ruled by the shortest movement in the piece, which will need to be of readable size; everything else will need to be accordingly larger. In illustration, say you have a two-movement piece of 30 minutes: a 1/2 second movement and a long movement of 29 minutes and 59 and 1/2 seconds. If the first (short) movement takes 1/8th of an inch so as to be readable, your whole piece will require 37.5 inches of physical space to score—significantly more than the sentence or two I used to describe describe it just now. More to the point: Labanotation is not efficient in edge cases. You can, of course, circumvent this limitation with free-form notes, but these are not part of the notation system and cannot be parsed or processed in any systematic way.

Another criticism has been becoming increasingly clear in writing this: there is no freely available definitive specification of Labanotation. A Google search only finds regurgitations and paraphrases of the original Kinetographie Laban. I don't think any of the work is still under copyright, so it must simply be lack of interest or resources. As a result, not only is the practice of Labanotation limited to only a few people with extraordinary expertise, but these same people must be entrusted with teaching the practice to others. With such a limited user base, and no real plan for expansion of that user base, Labanotation is likely to stagnate, become obsolete, and eventually be forgotten. Or did it do that already? Labanotation, and movement notation in general, like software, could benefit from a what Eric S. Raymond calls a bazaar-style development model, which depends upon a freely available specification. If anyone could learn about and contribute to the specification of Labanotation, it could easily adapt to new and unforeseen applications like computer animation—that would in turn create more resources for its development.

Detour: Music Notation

It's already quite clear how Labanotation is similar to classical western music notation, and indeed Laban was heavily influenced by it. Classical music notation, however, has been greatly expanded since; from experimentation upon the classical foundation like many of Terry Riley's works, to the development of Musical Instrument Digital Interface (MIDI) and more recently Open Sound Control (OSC). These latter systems have been instrumental (excuse the pun) in new applications for audio like video games and acoustic research.

Dance notation, however, has not seen any such advancements. New applications that could have used a modern movement notation system have either been doing without, or inventing domain-specific systems that cause fragmentation of the community and knowledge base.

It's important to note, however that MIDI and OSC are not notation systems per se, so much as control systems. That is, it wouldn't be very useful to transcribe Bach into OSC, but it could be done. OSC works at a "lower", less abstract level than classical music notation. There's no standard way to describe music that deviates from the forms allowed for by classical notation, that lies in the space between OSC and classical notation. In most of the scores I've seen, composers resort to either natural language notes to the musician or invented symbols, eg. Terry Riley's score for "In C" is accompanied by two pages of "Performing Directions". Labanotation takes the same route in these cases.

Obviously, a non-standard approach to music (and dance) notation works well enough. A standardized approach, on the other hand, would allow machine-readable scores so that something like a Bach score could be transposed to OSC control commands automatically. It would also allow human readers to understand a score without needing to know English or anything else external to the notation system itself.

So What?

I'll cut to the chase here. This is what I would like to see from a notation system for dance:

1. Describe any movement of any object in any time format
2. Control structures and logic for defining procedural scores
3. Be usable

1

This is pretty self-explanatory. One should be able to describe facial expressions as well as a dancing octopus. This will ensure that the notation system is application agnostic—that it can be used for any dance form, video game characters, and the orbits of planets.

There are many strong arguments that dance is more than physical movement (viz. my earlier example of Butoh). I think it's important to deliberately avoid that particular issue. So this is maybe more precisely a movement notation system as opposed to a dance notation system.

2

Basically, the notation system should be Turing complete. This will ensure that it can describe just about any conceivable set of movements (unless you want a dance version of The Busy Beaver Game). As such, it would be able to express exceedingly complex procedures and relationships of movements without deviating from the standard.

One might argue that it will remain more practical to express some movement concepts in natural language. I would counter that the notation system should actually be based upon natural language and thereby include language's full expressiveness. A computer language is intended to communicate instructions and data to a computer via machine code. Likewise, a movement notation system is intended to communicate instructions and data to a person, and can therefore use natural language instead of machine code as the indivisible underlayer upon which the entire system is built.

Laban already did exactly this when he laid out Labanotation, and this is also how every choreographer I know of works; they describe movements in words, which the dancers then translate to movement. The fact that the words are ultimately translated (compiled) to movement maybe makes a low-level language like C a better analogy for the role of natural language in dance than machine code. It's an interesting problem to choreograph entirely with movements, and not impossible; but for the purposes of a movement notation system I believe it's a reasonable concession that it function with natural spoken/written language as the lowest level of information.

3

Usability is a big goal, and never definitively obtained. Probably the most important aspect would be to work at multiple levels of abstraction, eg. if I want to talk about the dancer in simple terms of arms and legs, or in specific terms of the surface of the skin and eye movements, I should be able to do both and move seamlessly between them. Furthermore, I should be able to describe a group of dancers using the same notation system but without unnecessary verbosity.

This is a goal that many computer languages are only beginning to obtain by allowing the user to wrap low-level languages in higher level languages, and even use the low-level languages inline. In concept, however, abstraction is a hallmark of modern programming, allowing code reuse and thereby enormous gains in productivity and readability.

If the new system were abstractable one could re-implement something like Labanotation as an instance of the new notation system without losing much (if any) functionality. This would speed adoption of the new system while maintaining compatibility with previous systems like Labanotation and not sacrificing functionality.

Lastly, like code-reuse, abstractability would help people collaborate by sharing generalized snippets of choreography. If a choreographer wanted to choreograph an octopus (again), he could borrow a "library" of octopus movements from another choreographer that had previously worked with octopuses without needing to manually define a movement vocabulary. Likewise, video game houses could share libraries of character movements, rather than hiring actors at great expense. It could also open up enormous creative possibilities for remixing choreographic elements from multiple choreographers.