Francis Edward Simon Hunt
George Politis
and
Don Herbison-Evans
Basser Department of Computer Science
Technical Report 343
University of Sydney
(updated 14 October 2003)
Labanotation is a language for representing human movement. The components of this language are a number of symbols that represent positions and/or actions. Labanotation is, however, a complex language and it can be very time consuming and painstaking to use. A graphics-based computer editor is well-suited to the task of constructing a "score" in Labanotation because of the graphical nature of the language. Some computer editors have been written but none make full use of the current state of user interface technology. The editor developed here does this, using windows, menus, a bitmapped display and a mouse as a selection device. The use of the editor is described elsewhere, and the source code is also accessible. The editor, LED, is only a prototype for a larger scale editor and was written to test interactive principles rather than to provide a notation tool. We hope to stimulate discussion of what sort of user interface notators would like, so that we and other software writers can provide more useful products.
This movement notation system [Hutchinson 1973] was invented by Rudulf Laban in the 1930's. It has been used for dance, physiotherapy, ergonomics, and sport. It is based on a staff that runs vertically, with time running notionally upwards. The staff has 3 lines, and symbols each side of the central line denote movement and placing of the parts of the body supporting the whole body on the ground (the absence of symbols here meaning a jump or fall). Symbols for the right side of the body are placed on the right of the centreline, symbols for the left side on the left. By default, the feet (and hence legs) have their movements put beside the central staff line. Gesturing movements of the legs are notated in the next 2 columns out (inside the outer 2 staff lines). The next columns out, just outside the outer staff lines are used for torso and head movements usually, although each sign here has to be preceeded by the sign for the body part that is moving. The next pair of columns outward are for the arms, and do not need body part signs for simple movements. Further details of movement can be notated in further columns outward from the 8 so far described. There are signs for every part of the body, and modifiers for various amounts of movement, and various coordinate systems (e.g. room based, torso based, limb based). The notation has several thousand different symbols, and in general can be used to describe any visible human movement to an arbitrary level of detail. Only a tiny subset of the symbols have been implemented in this editor.
As with anything as complex as a human movement notation system, there are problems with its use. The very fact that a notation system must enable a notator to record any movement in meticulous detail, necessarily makes it complex and consequently hard and time-consuming to master. The wide range of movements that can be performed by the human body necessitates a large number of symbols in any notation system that intends to describe them in detail.
The process of using a notation system to record accurately a dance or any other sequence of movements is a very exacting and time-consuming task. To notate a dance properly, for example, a highly skilled notator is required. Such a notator is required not only to have a good knowledge of the notation system and an ability to accurately draft the score of the dance, but would ideally also have a knowledge of dance to make his/her job easier. There are few such notators in existence even today.
Frequently, a notator is hired to notate a dance as it is created, while the choreographer and dancers practice and refine the dance. As the dance itself is refined, so is the dance score. When the dance has been developed and learned properly by the dancers (which can take some time) a final score for the dance must then be properly drafted. All this is a long and consequently costly process.
A problem with the score that is produced by hand this way is that it is not easy to change it to any significant degree. In Labanotation, for example, where the score is a continuous piece, to change a few movements in the middle of a long sequence is not easy to accomplish. A means of quickly constructing and easily editing scores without compromising their accuracy is needed.
With the advent of improved technology, it has become possible to achieve a high quality of graphical representation on a computer. Graphical editors have been written that enable a notator to produce and edit a dance score for several Movement Notations. These editors provide the user with a choice from a given subset of the symbols in the language that they provide. The subsets are sufficiently large that they provide a reasonable chance of being able to reproduce the score of a dance or other sequence of movements.
A computer-based editor has many advantages over the notator-draftsman. Firstly, it is faster and consequently, after an initial high outlay, proves to be cheaper in the long run. Secondly, scores created on the computer can be easily modified. The score can also be saved into a file on the computer or disk and recalled for late modifications. It is also easy to then find a score, recall it from the file and quickly obtain a printed copy of it. Finally, if designed properly, the computer system will always produce high quality scores that are very accurate. "Previous Editors"
To date the best editors have all been written for Benesh. In terms of finished product there may be no great difference in quality between these and other editors, but it is in the area of the user interface that they stand out. Some rather good ones are Choreoscribe [Dransch 1986], BED by Hagist on the SUN workstation [Hagist 1986], and MacBenesh by Ryman for the Macintosh [Marcovici 1987]. These editors are both quick and easy to learn to use. The quality that makes these better than other editors is the design of the user interface (in particular, the use of windows and the mouse for selection of objects).
A number of editors for Labanotation have been written, some of a better standard than others: CCP [Calvert 1980], Calaban [Adamson 1987], NOTATE by Sealy, Allen and Anderson [Sealy 1978], LABA by Brown and Smoliar [Brown 1976], LabanPad, and CHOREO-L by Savage and Officer [Savage 1977]. There also exist some `editors' written for the Apple Macintosh - LabanWriter [Karl 1987] and LCsLN [Dunin 1987].
CCP has since evolved over several years into the "Lifeforms" animation system.
NOTATE assigns a symbol to each key of the keyboard. After selecting a symbol by typing the corresponding key, a user is prompted with questions on its length, shading and other attributes. The symbol is then positioned on the staff using arrow keys. There are major problems with this setup: an unfamiliar user must either take time to learn the use of each key (which may be different at different times during the use of the editor) or else continually consult a reference chart. Assigning the symbols to keys also limits the number of symbols that are available to the user, making expansion of the program difficult. On the whole, the effect of having to select a symbol and then to answer questions on its attributes proves to be rather tedious and time-consuming.
Similarly, LABA uses the keyboard as its means for input. This is an unsatisfactory method both for its problems with time and the difficulty that it often presents to users who are unaccustomed to computers. LABA, for some reason, also appears to have been implemented without the ability to produce hard copies (on paper) of a final score.
CHOREO-L is perhaps the best system so far produced for Labanotation. CHOREO-L is not just another editor, but also an interpreter - as the score is entered, a figure performs the movements entered. The score is entered using a set menu on an acoustic tablet. A symbol is selected from the menu on the tablet and then placed on a small staff section on the tablet (which represents the position currently at in the score). However, problems do exist with this setup as well. The number of available symbols is again limited by the size of the tablet. Also, a user must constantly transfer his/her attention between the tablet and the screen.
Calaban also uses a data tablet, which limits the display of symbol repertoire, and requires continual attention transfer. Also every direction symbol requires sizing individually.
LCsLN is unusual in its approach in that it does not retain information on the symbols in a score, but requires the user to manipulate bitmaps. LCsLN consists of a number of Macpaint/Fullpaint files that have already been constructed by its author. These files contain standard scores of different measures and most of the symbols required (in varying sizes). To use this `editor', Macpaint is first opened up. The user then opens up one of the score files and uses this as a base, saving it under a different name. To get at the symbols, a symbol file is opened up. The symbols are copied into the clipboard by tracing a line around them and selecting copy. Then the base file is re-opened and the contents of the clipboard pasted next to the blank score. Now the user can begin using these symbols by selecting them and copying them onto the staff. This process is time-consuming and rather cumbersome to use for a long period of time but can be improved if the user has Fullpaint rather than Macpaint. Fullpaint allows multiple windows to be open and also has a much better selection capability than Macpaint. The major problem with LCsLN is that it is merely a bitmap manipulator. The system has no underlying knowledge of the language that is being used and therefore can not interpret the notator at work in any way.
LabanWriter appears to be the most promising of the existing systems. Future additions to LabanWriter should make it one of the easiest notating systems to use because it is a graphical editor that requires the user merely to select from menus using the mouse. It still suffers from the same problem as LCsLN, however, in that it does not retain any internal information on the symbols and thus does not interpret the score in any way.
Hence, although these all represent marked improvements on the old technique of hand drafting scores, more can be done. Notably, more attention needs to be paid to the design of a better user interface to these systems. At the same time, it would be very useful to maintain some internal knowledge of the score so that syntactic errors in the score can be indicated. This includes errors such as placing the symbols in the incorrect columns or attempting to shade or scale the wrong type of symbol.
An ideal editor is easy to use and easy to learn. One of the best ways to produce such an editor is to model it as closely as possible on the way in which the person that it emulates would act. A clearly defined User Model based on the actions of a notator is required for the production of a good editor for Labanotation. Further, an editor should make full use of the currently available technology and methods of providing a good user interface. This must include the use of a mouse as a selection device, minimisation of keyboard use, menus and a windowing system. Previous editors that provide a good indication of the type of interface in question are BED and MacBenesh.
Past attempts to produce editors for Labanotation have paid too little attention to existing material on the importance of a good user interface as emphasised by Newman and Sproull [Newman 1979]. The very nature of the editor makes it most important to provide a good interface with the user. Not only will a good interface make the editor easier to use, it will simplify the task of learning how to use an otherwise very complex system. Finally, the potential users of editors for movement notations will almost certainly be unfamiliar with the use of computers. Consequently, it is of primary importance that the editor should be easy to use, self-explanatory, consistent and easy to learn. To provide all this, a good user interface is essential.
As well as this, the editor must retain a working knowledge of the score being entered. In this way the task of the notator can be simplified by having the editor correct small syntactic errors by not allowing them to occur. If, for example, the user attempts to place a symbol in an inappropriate column, the symbol should be deleted, thus never being inserted into the score.
A second advantage in having a well-defined internal representation is that any subsequent processing such as an interpreter becomes easier. Examples of the interpretation of Labanotation can be found in CHOREO-L [Savage 1977] and Brown's LABA [Brown 1976]. David Sealy also mentioned a form of internal processing in his system, NOTATE [Sealy 1978].
This project represents an effort to design such a system with an internal knowledge of Labanotation and a well designed user interface. The initial interface that was designed was tested in an implementation on the SUN 3/50 workstation in the C language using SUNCORE graphics routines, running under the UNIX operating system. The program has since been modified in the light of that experience to run under X-Windows.
There has been some past work on Labanotation that involved lexical analyses. Notably, Smoliar [Smoliar 1978] had produced one for use with his system [Brown 1976]. This analysis provides a simple breakdown of the most basic elements of Labanotation. It is not a complete analysis - which is not very surprising when one considers the size and complexity of the language, but does give a sufficiently large enough subset for purposes such as this editor.
A problem with Smoliar's result, however, is that the data structure that he associates with his analysis is intricate. Despite his claim that the combination "fulfills the requirement of convenience between notator and editor and between editor and compiler", it is a very complex data structure for something that can, for the main part, be represented by a simple array. In any case, a user should not need to have any knowledge of the underlying data structure and thus the data structure should not affect his/her use of the editor. As for the relationship between the compiler and the editor, the less complex the data structure is, the easier it will be for the compiler to process and access it. In fact, a simpler data structure should provide a better degree of efficiency simply because it is easier to work with and quicker to process.
The lexical analysis used in LED then, although similar to the one given by Smoliar [Smoliar 1978], has been designed with an array in mind. The array is to have elements that consist of a number of attributes that provide sufficient information to construct any of the symbols made available by the editor. A detailed description of the data structure and the attributes used is given in Hunt [Hunt 1988].
The basic requirement of the system is that it enable the user to produce a Labanotation score. To produce these scores, it would be ideal to have provided all possible symbols to the user, but time constraints have made it necessary to reproduce only a subset of the entire language. This subset is enough enable the user to compose a large part of many scores using the editor. Some touching up by hand is necessary if symbols outside LED's repertoire are required.
An important feature of the system is that the scores that can be created can also be edited. Once part or all of a score has been created from the menus of symbols that are provided, the user can edit what has been done.
Scores can also be saved to and recalled from files. In this way, a permanent record of the score is maintained and it can be retrieved for modification at a later date.
The approach taken in implementing these functions has been that they should be simple and quick to use. This means that the command language should be obvious even to a relatively new user and that it should take little effort to learn it.
Although the advantages of a computer editor for a notator are great (in terms of time and accuracy), few notators will have more than a passing familiarity with computer systems. In fact, the only knowledge that it is safe to assume a user will have is a background in Labanotation itself. Notably, it may only be expected that the user will possess sufficient familiarity with the language to enable him/her to compose a Labanotation score.
A consequence of this expected unfamiliarity with computers amongst users of the system is that the editor must be very user friendly. By this it is meant that the methods involved in composing a score should be both simple and easy to learn. As well as this, the system must provide ample feedback. This may take the one of two forms. It could be as simple as the immediate response of the system to a user's command or it could be the display of information messages when a delay or an error occurs.
The LED editor contains the following five entity classes:
The user is able to access script files that have already been created with the editor and also create his/her own files.
Operations on the script and the list used for the internal record of the script go hand in hand. Since they both represent the same thing, when one is altered, the other must be updated as well. Once a script has been made from a file or created from scratch, the user will wish to perform operations on that script. The available operations are editing, viewing, saving and printing:
When a script file is selected, it is read by the editor and the script that it contains is drawn and stored in the array of symbols. The operations on the script are, essentially, operations on this list. The actions that the user can choose from are:
The user interface is the view of the system that is presented to the viewer. Newman and Sproull [Newman 1979] and, with a little more detail, Foley and Van Dam [Foley 1984], divide the definition of a user interface into four different (but not totally separate) components: the user's model; the command language; information display; and feedback. A description of each of these components for LED is given below.
The editor itself is intended to behave in a similar manner as possible to a person putting a script together. The basic method of putting together a score - select a symbol and place it on the score - is the same. Conceptually, the two are the same, but they have different ways of producing the same result.
A user refers to a number of menus that show all of the available symbols while the draftsman/notator selects one of them from memory or a list. They both will then position it at the desired place on the staff. A symbol already on the staff can also be selected by the notator and some simple operations applied to it. The selected symbol can be moved, deleted, copied or modified - the difference being that the user of the system can perform these operations in one go. When a symbol is copied or moved, it is retained in a temporary location by the system and can be inserted into the script at another position.
In effect, then the system simulates a user who has a reference list of the symbols in the language at his/her side sitting down in front of a particular page of a score. He/she can refer to this list (i.e., the symbol menus) to select an item and then places the selected item on the page. Symbols that have already been placed onto the page can be copied, moved, modified or deleted.
The scrolling simulates a window looking onto the script. The 'UP' arrow moves the window up the script, and the 'DOWN' arrow moves the window back towards the beginning of the script.
There are two types of objects available to the user: intrinsic objects and control objects. The intrinsic objects are the natural components of the editor: the symbols. The control objects, employed by the user to direct the actions of the editor, are:
There are a number of operations on the above objects that are available to the user. In terms of what can be done to these objects, the operations are:
The basic tool of a user is the mouse. All operations available in the system are executed using the selection and positioning capabilities of the mouse device. Selection of an object or an action is performed by simply moving the mouse so that the cursor is located on the object desired and then pressing down one of the mouse buttons.
All the commands are initiated using the mouse. The commands have a pretfix syntax - i.e. the action to be performed on the object is chosen, followed by the object to which it is to be applied.
Abortion of commands is simple. If the user selects an object by pressing the mouse button down and then decides that an error has been made, the object can be deselected by releasing the button in the "wrong" place. If, for example, a symbol is being moved to the score, it can be disposed of by merely releasing the mouse button at a position that is not on the score, either overlapping one of the menus (when it will automatically be deleted), or dropping it somewhere away from other score symbols, and then "deleting" it.
Some errors are handled by the system. Since operations on the symbols on the staff act on selected sets of symbols only, the action can often be easily reversed before the next action is performed. If, for example, the wrong shading is selected, the process is easily reversed by simply selecting the initial type again. Anything that appears to be an error and is syntactically incorrect (such as selecting empty space) is indicated by a "beep" of the display. Perhaps in the future, a more sophisticated editor may even be able to warn the user of semantic errors, such as being in the air too long, or breaking the step-gesture rule.
There are also undoubtedly some errors in the program software. We will try to fix these as we encounter them in our use of the editor. If any are found, please let us know.
There are also errors in the X-Window system under which the program operates. One, which the authors found, was that the (x,y) coordinates of the mouse position were reported to the program in variables called y and x repectively: i.e. they were swapped. In different versions of the X-Window system, these variables may be reported correctly to the program, and hence the source code will need modifying to swap the variables back to their more appropriate use.
Another error in the X-Window system causes LED to ignore the first menu command given to it. This can be easily checked by trying to increment the BARS Command menu until the grid count in the BARS menu box actually changes. After this, the commands seem to be processed as programmed.
Other more serious problems were encountered with the X-Window system available to the authors, which seemed to involve internal races of different parts of the X-Window system against each other, and getting out of syncronisation with itself. It also sometimes fails to perform its memory garbage collection appropriately, and runs out of memory. Both of these problems cause LED to crash at unexpected times with incomprehensible error messages. As a precaution against the loss of work that this might entail, LED writes its score out to a file every time an item from the COMMAND menu is selected
These X-Window problems made continuous scrolling impossible to implement, and hence the (less friendly) half frame jumps have to be endured in lieu.
Another X-Window problem seems to be associated with bits of symbols left lying about on the score when symbols are deleted or moved. These phantom part-symbols eventually can clutter the script up so that it is hard to see what is really there. For this reason, a REDO command was inserted into the Command menu. The REDO command clears the screen and redraws all the current symbols afresh, clearing away the phantoms in the process.
Another annoyance is that when a pop-up menu is removed, because it contains 4 windows, the program gets 4 expose events, and so redraws the window 4 times in quick succession.
The internal record of the script is updated whenever any action is performed on it and the user's view is also kept up to date. Every time a user makes a change to a visible part of the score, he/she can see the results of that change immediately.
The layout of the screen itself is illustrated in Figure 1. The Command menu appears down the righthand side. The symbol menus are visible beside it. The scroll menu boxes are at the upper and lower ends of a scroll bar on the left-hand side.
The area of the score that is visible to the user has been selected so that it can contain about 20 or 30 symbols placed end to end. This provides enough space for about 4 bars of conventional music, and allows the use of a size of symbol on which the details are easily discerned.
The staff has been constructed on a grid of squares which are sized so that the side of one square is equivalent to the width of one column and also equal to one half of the length of a standard length symbol. This ratio was chosen firstly because it has proven to be convenient in defining the symbol shapes and because its simplicity makes it easy to implement.
The grid itself may be shown or rendered invisible by alternate hits of the GRID command menu box.
Feedback is continuously provided to the user. Every time an action is requested, visible results are immediately produced. This may take the form of the actions results (in cases such as positioning a symbol) or, in the case of slow commands such as read and write, some indication of the command status via changes to the colour of Command menu items that have been selected.
Selected objects are always indicated as such: symbols selected from a symbol menu move with the cursor; actions selected from a Command menu are changed to red to show that they have been selected.
The basic design of the system has centered around the need to provide a simple user interface. The best way to do this is to make the command language as simple and short as possible while keeping it consistent. In this way, new users will be able to master the editor quickly and experienced users will be able to perform the actions quickly.
The advantages of having a computer-based editor are not only its speed, however, but also its accuracy. Using the computer enables the programmer to provide a very high degree of accuracy in the finished product, but this must be measured against the ability of the user to make use of such high accuracy.
Thus it has been possible to provide the user with both the means of placing the symbols anywhere on the staff ("FREE" mode) or alternatively placing them at exact grid positions ("SNAP" mode). The grid is visible in that its corners are marked on the staff by dots. In "SNAP" mode, when a user places a symbol on the staff, the symbol is immediately lined up with the grid. This makes it easy for the user to place simple symbols on the staff, but makes it hard to generate compound symbols accurately, so these are often best constructed in "FREE" mode.
A further feature of the speed of this editor is that the user can quickly transfer his/her attention from one part of the editor to another and still continue to use the editor. With keyboard-based editors, for example, the user must continually transfer his/her attention from the keyboard to the screen and back again. A similar problem occurs if a graphics tablet is used. With a mouse as a selection device and the advantages provided by on screen menus (visibility, control and speed), however, the user need not remember a long list of commands and can execute those that are available very quickly and easily. In fact, one of the aims of this editor has been to, as far as possible, remove the need for the keyboard. The result is that the only time that the keyboard is required is when the name of a file must be entered.
A problem of design was the format of the scrolling. Either the score could be scrolled up/down, or alternatively the window onto the score could be scrolled up/down. These two alternatives involve opposite interpretations of the up and down pointing arrows. It was decided to scroll a notional window through which the the script is viewed, so that the "UP" scrolling arrow moves the window up the script, and of course makes the script appear to move downward. This is the paradigm used by other programs with scrolling capabilities, e.g. xterm, netscape. Thus the scrolling of LED will prove familiar to most people with some computer experience. Hopefully, dancers with no experience of these other programs will still find the LED scroll arrows intuitively comprehendable.
One limitation of the scrolling capabilities is that the score does not appear to scroll continuously when the scroll menu boxes are activated. Rather, the score jumps to its new position (each hit on the up/down arrows moves the score half a screen). This is unfortunate, and limits the intuitive understanding of the scrolling process but is currently limited by problems in the X-Window system available to the authors.
Another problem is that conventionally, a Labanoation score is read from bottom to top, whereas X-Windows addresses the screen from top to bottom. So there is a choice of which coordinate system to use in the bulk of the computer program. We decided to use Score coordinates, with "x" going from left to right, and "y" going from bottom to top. Only in the calls to X-Window routines is the "y" parameter reversed.
Another decision to be made was how many symbols and symbol menus to present to the user. In a preliminary version of the program, the symbol menus were arranged to be of the "pop up" variety, only appearing when they were called from icons in the Command menu. The user was also given the facility of being able to move the menus about, and stack them over each other. However, in use, this was found to be tiresome, so in this later version the symbol menus have been tiled. This makes it much easier to use, at the price of having less space available for the score, and it also limits the number of symbols that can be made available.
Another choice to be made in the programming was how to provide the user with bar lines. In the current version, the grid spacing of the bar lines can be chosen by the user, and then the lines inserted, with the first two being special for notating a starting position. Also bar numbers are inserted automatically. This is the default. If the user prefers a different arrangement, he/she has to delete/move the presented bar lines and numbers.
The data structures used in this system were based on the lexical analysis given above. A score is represented by an array of symbols.
Each basic symbol is represented by a single element in the array. There is also additional information stored for modifiers to the symbol (for example: a direction symbol will have its level, length, shading, and position on the score stored also).
The structure used in setting up the array has fields as in Table 1.
The "menu" field indicates which menu the symbol came. Each of these values for "menu" refers to one of the major classes of symbols arising from the lexical analysis given above.
The "item" field indicates which symbol in the menu was copied.
The fields "x", "y", "w", and "h" are used to store the information on the position and size of the symbol.
The "step" field is the length of the individual strokes composing the symbol.
The "level" field indicates whether the symbol is filled by either blank, a dot, a hash pattern or solid black.
The field "ok" is used to indicate whether a symbol is still wanted on the score, or has been deleted.
The field "hit" is used to indicate when a symbol has been chosen by the user for some action.
The fields "prev" and "map" are pictures of the area obscured by the symbol and of the symbol itself.
The field "done" indicates whether the "prev" and "map" fields have been filled.
RESULTS
The utility of LED may be judged by viewing the scores of the 23 approved competition and championship New Vogue dances such as the Swing Waltz, which were prepared using LED.
Also,one of the authors (FESH) compared the production of some sample scores by computer (Figures 2 - 6) with their production by hand.
The scores are copies taken from the following texts-
"Second port de bras" from "Study Guide for Elementary Labanotation" [Hackney
1977].
"The Charleston" from "Labanotation" [Hutchinson 1973],
"Turn about the room" and "funny walk" from "Dance Notation for
Beginners" [Brown 1984]
"Plie" from course notes by Dr Drid Williams [Williams 1988].
A number of things are noticeable when comparing hand written scores with those produced with this editor. Firstly, the scores drawn by hand are not nearly of the same quality as the computer-generated ones. This is not just a reflection on the sloppiness of the author who drew them and his lack of great skill as a draftsman, but a distinct indication of the greater accuracy that the computer offers.
Looking closely at the hand drawn versions, it is also possible to discern some errors. This was an unintentional result and came about because they were being drawn as fast as possible. Mistakes were also made when when using LED, but it was very quick and easy to correct or remove these mistakes.
The reason that the hand drawn scores were drawn rapidly was that they were being timed so that some idea of the efficiency of the editor could be determined. The times taken to produce the scores is given in Table 3.
The times shown in the table do not include the time taken for hand drawn scores that were thrown out because the errors had become too much.
It appears that LED provides a greater speed than does drawing the scores by hand as well as offering other advantages of consistency, storage, retrieval, and easy error correction.
The editor still has a number of problems.
One is that the bar lines extend across all of the staves, rather than staying within each triple line staff. A little surgery will be required to fix this.
Another problem is that sometimes, when taking a copy of a symbol from the DIRECTION menu, the symbols remaining become corrupted. Luckily it appears only to be an imaging problem. Redrawing the window clears the corruptions. This is a subltle bug in the interface between the LED C program and the X-Windows graphics routines, and is taking a lot of ferreting to find its cause, and to fix it.
Another nasty little snag is the gaps that develop between symbols, leaving some ambiguity about whether a little jump is being notated between steps. The problem stems from the fact that the direction symbol heights should really be a number of pixels that is a multiple of 6. This is because some have a change of shape halfway, and some have a change one third the way along. So a default length of 12 pixels was chosen for direction symbols, and a spacing of 1 pixel between vertically adjacent symbols chosen for readability. Thus for a waltz, with 3 movements per bar, the bar line spacing would be 39 pixels. However, if only one movement occurs in some bar, the symbol will have a length of 3 x 12 = 36 pixels, leaving a 3 pixel gap at one end. Curing this will require som restructuring of LED to allow symbol lengths to be other than a multiple of 6 pixels long.
In view of the compromises described above, LED does not provide all the symbols that make up the Labanotation language. Nevertheless by using and combining the symbols provided, many commonly used symbols can be generated. The ease with which scores can be produced with the editor is its greatest advantage over the traditional method of drafting them by hand.
Past experiences have shown that the construction of a Labanotation score is time-consuming, tedious, costly and painfully exacting. This comes about because of the detail required to notate even very simple moves. The computer editor provides a very good means of solving these problems because the computer enables the user to compose a score accurately with much less effort.
As the language is well-defined and structured, the editor can be given the power to control the composition as it is created. When a symbol is placed on the staff, for example, the draftsman who notates by hand must rule it in precisely with pen and ruler while a user of the editor need only approximate the position because the editor will line up the symbol with a predefined grid.
The editor also provides many other features that are not available to the draftsman. A score can be quickly and easily changed by a user of the system in many ways. Existing symbols can be deleted, copied, moved to another location, or changed in size or level. The operations to perform these changes are all readily available to the user of the editor at the click of the mouse button. The quick accessibility of these operations makes the editor a very fast tool for writing a score.
Another feature of the editor is that existing scores can be saved away and restored at any point in time. This provides the user with a further dimension in flexibility that the draftsman can not even contemplate. A score can be quickly recalled and modified on the spot. This is an invaluable advantage since it can often be very messy to insert changes into a hand written score. The editor, however, can readily modify existing symbols.
The initial aim of the project was to design a good user interface for a dance notation editor and to validate this design with an implementation. Although initially hampered somewhat by the use of SUNCORE, the system that was implemented showed that a design involving windows and menus with the mouse as a selection device has a lot to offer. The availability of a computer with the capabilities of a SUN 3/50 has proved to be advantageous in that the bitmapped display provided a high degree of accuracy, the graphics package provided many of the built-in functions that are used in the implementation, and the connection to a printer of the quality of the laserwriter enabled the production of very precise scores.
Overall, however, the editor has proved very easy and quick to use. It operates on the simple principle of pointing the mouse at a desired object, pressing the mouse button and "dragging" (i.e., moving the mouse while holding down the button) until the desired action has been performed.
The computer system used for this work currently costs several thousand dollars. However, computer prices are currently dropping rapidly. As "Very Large Scale Integration" (VLSI) of electronic circuits becomes commonplace, the price of a similar system may be expected to fall within the financial reach of even small dance schools and companies over the next few years. When this happens, the availability of a notation editor that is simple to use and provides a full visual repertoire of symbols may dispell some of the dismay which is shown by some dance professionals when considering notation. Such an editor may also be of value in teaching notation. The files produced by the editor also provide a resource for choreological research, a basis for translation between different dance notations (Politis, 1989), and for an interpreter to show animated figures for help with checking score correctness and teaching.
Thus it is useful even now to experiment with different ways that dance software may work, to find out what features are required. We feel that we have contributed a step in this direction.
One of us (FESH) is grateful to his fellow Honours students without whom he may have lost his sanity during a few long nights imprisoned in the Computer Science building, to his family for their support, and also to Amanda for her concerted efforts to remind him that there is more to life in an Honours year than a thesis. Thanks are also due to the reviewer (G. Miller) for many helpful comments on the original manuscript. We must also thank the staff in the Basser Department of Computer Science, University of Sydney, in the School of Computing Sciences at the University of Technology, Sydney, and in the Department of Information Technology at Central Queensland University both in Bundaberg and Rockhampton, for their forbearance and help, often under trying circumstances.
Adamson 1987. Adamson, A. Computerised Labanotation - Calaban, Department of Drama & Theatre Arts, University of Birmingham, U.K.
Benesh 1956. Benesh, R. and Benesh, J. An Introduction to Benesh Dance Notation.
Brown 1976. Brown, M.D. and Smoliar, S.W., LABA, A Graphics Editor for Labanotation, Computer Graphics 10 (2), pp. 60-65.
Brown 1984. Brown, A.K. and Parker, M. Dance Notation for Beginners, Dance Books Ltd, London.
Calvert 1980. Calvert, T.W., Chapman, J. and Patla, A. The Integration of Subjective and Objective Data in the Animation of Human Movement, Computer Graphics 14 (3), pp. 198-203.
Dransch 1989. Dransch, D.O.K., Beatty, J.C. and Ryman, R.S. ChoreoScribe, Computer Graphics Laboratory, University of Waterloo, Waterloo, Ontario, Canada.
Dunin 1987. Dunin, E.I. Guide to LCsLN, Department of Dance, University of California, Los Angeles.
Foley 1984. Foley, J.D. and Van Dam, A. Fundamentals of Interactive Computer Graphics.
Hackney 1977. Hackney, R., Manno, S. and Topaz, M. Study Guide for Elementary Labanotation, Dance Notation Bureau Press, New York.
Hagist 1986. Hagist, F. A Graphical Editor for Benesh Movement Notation, Basser Department of Computer Science, University of Sydney, Sydney.
Hunt 1988. Hunt, F.E.S. An Interactive Graphical Editor for Labanotation, Basser Department of Computer Science Honours Project Report, University of Sydney.
Hutchinson 1973. Hutchinson, A. Labanotation.
Karl 1987. Karl, G. MANUAL FOR THE LabanWriter PROGRAM (First Draft), Department of Dance, College of the Arts, The Ohio State University.
Marcovici 1987. Marcovici, M.M. and Ryman, R.S. The MacBenesh Manual, Computer Graphics Laboratory, University of Waterloo, Waterloo, Ontario, Canada.
Newman 1979. Newman, W.M. and Sproull, R.F. Principles of Interactive Computer Graphics.
Politis 1989. Politis, G. A Translator for Human Movement Notation, Basser Department of Computer Science Technical Report 350, University of Sydney
Savage 1977. Savage, G.J. and Officer, J.M. CHOREO: An Interactive Computer Model for Dance, International Journal of Man-Machine Studies 10, pp. 1-18.
Sealy 1978. Sealy, D., Anderson and Allen NOTATE: Computerized Programs for Labanotation, Journal for the Anthropological Study of Human Movement 1 (2), pp. 70-74.
Smoliar 1978. Smoliar, S.W. A Lexical Analysis of Labanotation with an Associated Data Structure, Department of Computer and Information Sciences, University of Pennsylvania, Philadelphia.
Williams 1988. Williams, D. Course Notes for Labanotation Classes: text and lessons, Department of Music, University of Sydney.
Table 3: Comparative Times Taken to Draw Representative Scores (minutes)