What new features would you like to see in LabanWriter 5?

What new features would you like to see in LabanWriter 5?

By David Ralley et al.

Submitted by DNB Staff – May 29, 2012

[The following discussion was originally posted on LabanTalk in March 2012]

---

From David Ralley, March 17

Hello,

Lucy Venable and I were having a discussion this weekend about the future of LabanWriter, and thought it might be wise to ask the members of LabanTalk for their collective input.

If funding for a new version of LabanWriter were to be found, what kinds of improvements would you like to see? 

These requests can include:

• bugs that you currently work around, but would like to see fixed-problems with workflow that could be made better (e.g. it takes me a long time to do this…I wish that were faster) 

• changes to the interface to make life easier for users-new features that you'd like to see in a new version.

To be clear, there isn't currently money for a new version of LabanWriter, but trying to figure out what a new version would entail would help us formulate a plan and estimate the amount of effort it would take to to make one. Your input would be invaluable, since it's the users who see problems, and probably maintain their own wish lists.

David

 

---

From Oliver, March 17

Hello David,

My wish would be: XML-based output format, using symbolic names instead of just numbers.

This is a feature that not directly has influenceon usability. But it has influence on exchangingscores with even non-Labanwriter users.

If exchange is something, that is of interest for LabanTalkers, then IMHO this feature is a must. Bzt if scores are only written for provate usage, then of course my feature wish is not worth adapting.

Ciao,

Oliver

---

From Gregory Shenaut, March 18 

If anyone is going to implement labanxml, I really hope they use musicxml as a starting point, and focus on movement in general instead of LN specifically, with LN being a special case of the underlying xml spec along with the possiblity of other notations as well as specifications for animations, sort of how musicxml can underlie either tablature or standard notation, or can be transposed into various keys or arranged in various sorts of individual parts or scores, or be used to generate a synthesized performance.

<http://en.wikipedia.org/wiki/MusicXML>

Greg Shenaut

---

From Oliver, March 18

Hello,

I looked at the MusicXML... and this looks really good. The stuff already is quite well developed. Even a set of DTD'sis already available online. Everyone could download and use themfor their own applications.

Even I think pointing to MusicXML as an inspiration for a LabanXML does make sense, it maybe would be even good, just to have a LabanwriterXML as a minimal starting point for exchange of scores, which also opens the field for other people adapting to it.

As budget seems to be very small in the LabanWriter project, maybe developing a LabanXML might be something that would need more iterations. (But using it as a guide into the right direction would be good.)

But bzw. there already is a LabanXML developed by a Japanese researcher. And this is not new. It was mentioned more than once on this list. Not sure if the Labanwriter team already contacted

these researchers.

In a MusicXML-FAQ which I found via the Wikipedia-page was mentioned, that Ohio State University has provided a format ("Humdrum") that was one of the two formats, that were the starting point for developing MusicXML.

So, for the LabanWriter-team, I guess it's just a short walk to have a talk to people involved in it.

Just some suggestions.

Ciao,

Oliver

---

From Vicki Watts, March 18

Dear Greg,

I know next to nothing about xml, but I am a notation specialist who works in both Labanotation and Benesh Movement Notation.  Your idea about writing the xml based on movement generally and not on Labanotation sounds excellent in principle.  I just want to caution that there is not a universally agreed conceptual framework for how we talk about, describe, analyse human movement.  You might want to take a look at Dr. Sheila Marion's doctoral dissertation (ref. below) for a thorough explanation of this issue just in relation to three different dance notation systems.  If I understand your post below correctly, any kind of movementxml would need to adopt a conceptual framework for notation based on an already proven system of analysis (e.g. Labanotation) or would need to be preceded by the invention of a new conceptual framework that can mediate between various notation systems and analytical frameworks already in existence.  Part of the problem, if you want to make an analogy with music, is that you'd be looking to find a way to analyse/notate ALL humanly produced sound, not just the far more limited (though admittedly still extensive) range of noises that fall within the parameters of the Western musical tradition. 

Kind regards

Vicki Watts 

Marion, Sheila. "Notation Systems and Dance Style: Three Systems Recording and Reflecting One Hundred Years of Western Theatrical Dance." New York University, 1997.

---

From Billie Mahoney, March 19

To David Ralley,

Thanks for asking. I have several bugs!

For starters:

My biggest gripe –

When a foot hook is dropped next to a low level leg gesture on the right side of the staff it jumps into the gesture symbol. Generally on the left side of the staff the foot hook contact will stay where placed. This is very annoying as it takes extra moves to get it into the right place, and placement of the timing for the contact is most important, This is a big bug for me, as most of my notation at this time is for tap dancing and there are foot hooks on every support and gesture symbol. I would like the foot hooks to stay where placed, so I don’t have to dig them out of low level symbols.

Copy and paste sometimes presents problems. Is it possible to indicate where the copied section can be placed? It always “pastes” in the middle of the page. If by chance the blinking stops, then the notated sequence on the middle staff really gets messed up in a jumble with the symbols being moved. And it takes an unnecessary amount of time to move a repeated sequence across the page if you are working at the beginning of the first or last staff. 

When a new staff is added to a page, it sometimes is placed on top of a previous staff, attaching to those symbols, which move along with the new staff to another place on the page. It seems I spend more time re-doing rather than being able to move ahead when trying to get the new choreography on the page.

When preparing kinetograms or examples for exams for students, which will be placed into a Word document, the space required around the one or two beat example, takes up a lot of blank space on the paper, sometimes more than the example itself. 

This is off the top of my head for now; might be able to give examples to clarify later. And will think of more problems to add. 

Thanks again,

Billie Mahoney

---

From Oliver, March 19

The MusicXML might only be useful for western music very likely will not be able to notate non-western music.

But it is a tool that helps at least in this area, as Labanotation or Benesh or any other Movement notation helps in the area they are used for.

It does make sense to start with something that can be used in one area, just using one notation.

To have a dataformat which only helps exchanging data of one specific domain or siubdomain is not a problem. It's a first step. And very likely different domains will need different data formats.

People do use text, if they write text, use notes if they write down music, use math formulas if they want to write down mathematical ideas, and use a movement notation, if they want to notate dance.

If there is more than one notation for movement, it might sense to start with different formats for any notational system, because doing that will be a task that is hard enough. In later stages, when the people got experience with these notations, and gain a more thorough understanding of how different notations can be translated, then there might be a meta-dataformat / meta-notation.

But a universal language was there as an idea for centuries. The problem was not solved, and might never be solved.

So it's better to start something, on which later generations could build on, and progress step by step.

I deeply doubt that it will be possible to make a general movement notation in an amount of time that can be pressed into the lifetime of one individual. I rather think this is something that will need some generations.

But wating for the perfect solution will not work.

Starting with a subdomainspecific format, like LabanXML, or maybe MotivXML, or maybe just only a LabanWriterXML would be a huge step forward.

At the moment there is nothing of that already in use.

The LabanXML from the japanese researcher, when looking at how much information it this format is available (and how much it is discussed here), rather looks like a myth. Does any real livoing person, who also is on this list, has ever seen a notation-file and it's usage seen in real world?

I only saw that in a short paper *about* it.

As this thread is about new features of LabanWriter, I think it would be overarching to await that the small LabanWriter team would do all the research that is necessary to get a work done that would need many people from many domains and countries and research on that.

As it is just about what additional features LabanWriter should offer in the future, I asked just for a better exchange-format:

  - XML-based

  - symbolic names for the elements in the notation

  - generally generic: possibility to attach a new timeline;

      each "instrumentation" (the vertical lines: right foot, left foot, ...)

      as a timeline.

      Adding new "instruments" could be just adding a new timeline.

      Synchronisation could be done via time information

Additionally, rather GUI-specific, I would like to have many often used symbols to stay on the GUI. See the LED-screenshot here:

  http://linus.socs.uts.edu.au/~don/pubs/led.html

I would make the palette even bigger.

As far as I remember LabanWriter (long ago that I used it), it has most of the menues hidden and  looking for symbols was time consuming. To have a big palette from where symbols can be selected more easy, would be a very concrete feature that I think would make sense.

But maybe it's already there; I didn't looked at some of the latest versions of LabanbWriter. (At the moment I have no Mac.)

BTW: Was there a decision on making it OpenSource? I remember that this was at least under consideration.

Ciao,

Oliver

P.S. Limelight had many windows...

        http://user.uni-frankfurt.de/~griesbec/LIME.HTML

      This has advantages and disadvantages.

      I think a one-window version (or maximum two windows) would be better.

      So LED's layout makes more sense to me.

P.P.S. There are no screenshots on the LabanWriter homepage.

        Adding some would be a good idea.

---

From Gregory Shenaut, March 19

I think this is a case where the best could be the enemy of the very good. If a new XML-based notation were developed that could represent solely the most commonly used elements of the most commonly used (if that's the right word) movement notation and animation systems, that would be very good, I think. With something like that as a sort of shared base representation, you could write XSLT or other scripts to: translate from LN, Benesh, ... into the XML base and then translate from the base to any of the above. If you had that, then you could trivially translate from one supported notation system into another, or into a supported animation program's code. You could also have a movement editor that would be notation independent, in that it could use any supported representation (including animation-based movement editors like DanceForms) to modify the xml base interactively, and produce any notation or an animated performance as output. Another piece of this puzzle is that if movement XML were implemented compatibly with MusicXML, there would be no reason why you couldn't merge the two and have a combined music/dance score, for example, that could be used to produce an animated performance with soundtrack as easily as it produced dance and orchestral scores & parts, or a have a merged editor that could work interactively with both music and dance (and staging, etc.).

To me, anyway, it's a little like looking up at the cloud-veiled heights of Kilimanjaro. A wonderful view, but the real work is still ahead. (But it all starts with one step in the right direction.)

Greg

---

From Vicki Watts, March 19

Dear Greg,

Again, in principle I agree with everything you say here.  However, I'll also point out again that different dance notation systems don't think about even the most basic elements of movement in the same terms.  Indeed, often it is these most commonly used elements of human movement that differ most widely in the ways different notation systems represent them (garbled sentence  - sorry).  The analysis of rhythm and timing is one such case in point.  I think I am really saying that if anyone were to continue to look at an xml-based Labanwriter they would be best advised to stick to the conceptual framework that the Laban system uses.  

I really like the suggestion you are making but as a bilingual notator I am struggling to see how anything like it is even remotely possible without either a) approaching all movement notation systems through the analytical lens of just one or b) devising a new analytical framework for movement that operates on a kind of meta level for all the other systems.  So, again I come back to suggesting than any xml development may as well use the Labanotation framework.

Would love to chat about this more at some point, but probably not for a month or two. Too many deadlines looming right now!

Kind regards

V.

---

From Leslie Bishko, March 19

In light of the question that David and Lucy pose: what would people like to see next for Laban Writer, I observe that there are important and significant research questions as well as bug fixes and ideas for general workflow development.

Considering the latter, my wish is for better support of Motif and Phrase Writing, and Laban Movement Analysis concepts.

Regarding XML, I am somewhat of an outsider/lurker on this topic, and would like to offer a few observations.  The research debates happening on this listserve are not necessarily questions for LW to address.  Any one here can pursue research funding, collaborate, and contribute to the knowledge base, which LW can then draw on for future development.  It seems appropriate to hold a symposium where those with related expertise and interest can kickstart these exciting new possibilities!

Leslie

---

From Sandi Kurtz, , March 19

"my wish is for better support of Motif and Phrase Writing, and Laban Movement Analysis concepts."

What she said!

sandi kurtz
Seattle, WA

---

From Linda Nutter, March 19

Like others, I too am a "lurker" on this list.  I teach Motif Notation and follow Charlotte Wile's book and methodology.  With regard to Vicki's comment, I wanted to recommend Ann Hutchinson Guest's book "Choreo-graphics:  A Comparison of Dance Notation Systems From the Fifteenth Century to the Present."  (Not to Vicki, of course, but to those who are interested in this topic.)  I feel that it provides a great introduction to the major similarities and differences between how the various systems perceive, analyze and notate movement.  Between reading this book and doing a little more research, I agree with what Vicki has said about sticking to one conceptual framework.  

Linda Nutter

---

From Marissa Nesbit, March 19

I second the inclusion of an easier way to use Motif Writing. While there are ways to create all the symbols I need currently in Laban Writer, sometimes this is a work-around. I would love an interface that aligns with the "family tree" approach in Language of Dance outlined in Your Move. The challenge there, of course, is that LOD is just one conceptual organization scheme and does not necessarily fit what everyone uses, nor would it align completely with structured notation. So, I recognize that this might not be an ideal approach for everyone's needs. But it would be lovely to have some type of way to easily access motif symbols.

Related to that, it would be nice to somehow have the option as a teacher to select only certain symbols/families that students could use. I don't know how such a "teacher control panel" might work, though. Or, to have an alternate interface that is easy for children to use. 

At some point it would be nice to have this work on iPad or other tablets, which would make classroom use more accessible in the future. It would be nice to use LabanWriter in the studio, rather than making a separate trip to a computer lab. This is, of course, part of the "one day we have a lot of resources to do this" fantasy.

Marissa Beth Nesbit

---

From Oliver, March 19

On Mon, Mar 19, 2012 at 12:00:32PM -0700, Gregory Shenaut wrote:

> I think this is a case where the best could be the enemy of the very good. If

> a new XML-based notation were developed that could represent solely the most

> commonly used elements of the most commonly used (if that's the right word)

> movement notation and animation systems, that would be very good, I think.

How many decades or centuries do you think will it need until such a notation will be developed?

That XML is used instead of other formats is not the hard part. The hard part would be to get a definition of movement that is so general. Using XML instead of a different (specialized) format does not really help, because using XML instead of any other format ist just helping to make the syntax part paresed easier.

But the hardest part for such a general movement notation is the semantics.

It would need to start at very basic mathematical-philosophical roots, like topology.

Maybe using mathematical XML formats as a starting point for a movement notation seem to be not the worst idea ;-)

Henner Drewes has discussed the problems of translating Labanotation into Eshkol-Wachmann notation and vice versa. He said to me, that - caused by the notation - the dances that will be done based on Eshkol-Wachman notation are qualitative different to those, notated in Labanotation.

They use different concepts, and they create a different reality. Any tool has impact on the creation and even feedbacks to the creator.

And a notation is also just a tool.

There were researchers showing, that the kind of music software you use, has influence on the music that is created with it.

The same holds true for movement notation and dance.

If you look at Merce Cunningham's dances...they somehow look robotic.

It's the result of what the tool (computer) allowed to create. Different software would have given different dances even with the same choreographer. (I don't say, the choreographer does not matter; but the tool maters also).

So a movement description (not necessarily "notation") that would be able to describe all these different concepts would mean a big research effort. And thats nothing, what can be done by the Labanwriter team alone.

You may remember that it was mentioned here on the list, that the money was used for other projects.

So I think, not overarching would help here. Even the small steps seem to be done in slow motion. So if you want to make siuch a big movie and look it in slow-motion, your grandchilds of your grandchilds will have a grey beard ;-)

Maybe the Labanwriter people could start with LabanXML (their own? Taking the japanese stuff?), and maybe Henner Drewes will be so friendly and use XML for the output of the program for Eshkol-Wachmann notation.

Then there will be two XML formats, and at least the syntax stuff of both formats can be done by the XML-parsers. The harder part of semantic analysis then would need be done by the notation experts. And I think, the Labanotators would be better in Labanotation than Eshkol-Wachman.

And they all will perfrorm badly on a notation that at the moment not even exists.

How to use a notation (or description) that does not even exxist?

> With something like that as a sort of shared base representation, you could write

> XSLT or other scripts to: translate from LN, Benesh, ... into the XML base and

> then translate from the base to any of the above.

Even different formats that can be parsed easily, will be of benefit. If there is one LabanXML and one Eshkol-Wachman-XML and one BeneshXML thats better than to have as many different formats (with different syntax as well as semantics).

> If you had that, then you could trivially translate from one supported notation system into another,

> or into a supported animation program's code.

But then the question arises: why to use these different notations, if there already would be a much more powerful description with this new notation/description system?

It might be used directly, and the old notational systems would only be history of notation.

But look: how many decades is Labanotation old? And how wide spread is it? And the more crucial question here would be: Did it come to an end?

Is Labanotation now ready and will not change anymore? If it does change: why? What is missing?

Just some new symbols?

But what about the rotational items (spherical coordinates) of e.g. Eshkol-Wachman notation?

If there already would be LabanXML (and be used widespread), as well as a Eshkol-Wachman notation, then from experience of it's use maybe one day a general movement notation/description can be created.

Maybe not. But without experience of this, I think such a big project as a general-movement-notation will definitely be incomplete and something will be overseen.

Than better starting with subdomain notations AND USE IT, instead of *only* phantasizing about the big revolution in movement notation. That goal can be a vision that motivates. But directly working onto it... I have my doubts that the weak dance (and weaker dance notation) community can fullfill such a big topic.

I think the already available notations are a powerful tools. If we just would be able to handle these well with computers, this would be a big step.

I think I'm on this list since about 10 years or so. 10 years no progress.

Look at other areas.... how fast they progress.

So I'm rather pessimistic on this issue here.

BTW: In this thread also was mentioned LabanWriter used for notating tap dance.

There was a very special notation (Kahnnotation), especially created for tapdance.

Just mentioning it for adding another notation here... ;-)

> You could also have a movement editor that would be notation independent, in that it could use any

> supported representation (including animation-based movement editors like DanceForms) to

> modify the xml base interactively, and produce any notation or an animated

> performance as output. Another piece of this puzzle is that if movement XML

> were implemented com patibly with MusicXML, there would be no reason why you couldn't merge

> the two and have a combined music/dance score, for example, that could be used to

> produce an animated performance with soundtrack as easily as it produced dance

> and orchestral scores & parts, or a have a merged editor that could work

> interactively with both music and dance (and staging, etc.).

I once also had these dreams (and posted them often to this list,

over the last years).

I think this will be a dream for the next two decades. ( Prove me wrong, please ;-) )

Ciao,

Oliver

---

From Hannah Kosstrin, March 19

Hi Marissa and all,

I have been following all the threads of the past couple months, and am excited about all the discussion. I apologize that I have not been able to respond as quickly or as timely as I wanted. Since it came up in Marissa's post, I just wanted to make a quick announcement that David Ralley and I are working on porting LabanWriter to the iPad via funding from Reed College and a National Endowment for the Humanities Office of Digital Humanities grant. It is an exciting project, and we are looking at some kind of release later in the summer. It is this very prospect of using LabanWriter on a tablet in the studio that drove the project, and we plan to have a touch input that is efficient for both Motif Writing and structured notation. While the current version is not open-source and is iPad-specific, with future funding hopefully future versions will be open-source across platforms. Please contact me off-list at the address below if you are interested in being a tester of the beta version of the app.

More on this project soon.

Best,
Hannah Kosstrin

---

From Oliver, March 19

Hello Linda,

On Mon, Mar 19, 2012 at 04:52:11PM -0400, Linda Nutter wrote:

> Like others, I too am a "lurker" on this list.  I teach Motif Notation and

> follow Charlotte Wile's book and methodology.  With regard to Vicki's comment,

> I wanted to recommend Ann Hutchinson Guest's book "Choreo-graphics:  A

> Comparison of Dance Notation Systems From the Fifteenth Century to the

> Present."

[...]

Thank you for posting this title. Years ago I had the possibility to look into this book, and found it very interesting. Then  I forgot the title...

Good hint. Thanks.

Ciao,

Oliver

---

From Oliver, March 19

On Mon, Mar 19, 2012 at 01:40:21PM -0700, Leslie Bishko wrote:

> In light of the question that David and Lucy pose: what would people like to

> see next for Laban Writer, I observe that there are important and

> significant research questions as well as bug fixes and ideas for general

> workflow development.

>

> Considering the latter, my wish is for better support of Motif and Phrase

> Writing, and Laban Movement Analysis concepts.

[...]

If not already done, add the symbols for body patterns (breath, core-distal, bodyhalf, ...).

Very useful concept (from LMA)!

Ciao,

Oliver

---

From Oliver, March 20

Hi,

On Mon, Mar 19, 2012 at 02:25:29PM -0700, Hannah Kosstrin wrote:

> Hi Marissa and all,

>

> I have been following all the threads of the past couple months, and

> am excited about all the discussion. I apologize that I have not

> been able to respond as quickly or as timely as I wanted. Since it

> came up in Marissa's post, I just wanted to make a quick

> announcement that David Ralley and I are working on porting

> LabanWriter to the iPad via funding from Reed College and a National

> Endowment for the Humanities Office of Digital Humanities grant.

Again (and so far) very Mac-biased. I wonder, if the LabanWriter project could ask Apple for funding, if it's so Apple-biased. They maybe also would add some manpower and the XML issue might be solved in some months.

Regarding the usage of computers vs. the usage of pencil and paper: any tool has influence on the result. Even an iPad might be very useful, the results for choreographing will be different than if the notation is drawn by hand and later using the computer. But the more "natural" a tool behaves, the better I think.

So the touch-screen issue will make sense.

[...]

> While the current version is not open-source

> and is iPad-specific, with future funding hopefully future versions

> will be open-source across platforms.

I hope it also will not be only "open source", but also FreeSoftware (Free as in free speech, not necessarily free as in free beer).

So maybe BSD license or GPL (GPL3), or some other similar license. "Open Source" alone does not help. It also must be free as in free speech.

See the explanations on free software here, please:

  http://www.gnu.org/philosophy/free-sw.en.html

I think the XML-issue is more pressing than making the software open (even I of course would see that happen).

The XML-issue is about exchanging notation. And that is, put into one term: communication.

Those who think the internet and the so called "web 2.0" (buzzword) has evolved quickly and amazingly, also would need to admit, that the base of all that is: communication, which means exchange of information, spreading ideas, ...

LabanWriter files only stay in their own small niche so far. The same holds true for Calaban.

No exchange, no communication. Hermetic closed small niches. No wonder that the dance notation issue is only used by some people, and not by many.

And even those who use notation, can't exchange their scores in an editable way, if they were done on either LabanWriter or Calaban.

So the language burden, that was mentioned between different notations of movement (that some people want to solve by a more powerful movement description) occurs also inside Labanotation and Labanotation, when looking at the exchangeability of notation.

In other words: there is not only a nborder between Benesh-, Laban-, eshkol-Wachman-, ... notation in exchange. There also is a burden in compatibility / exchange / communication between Labanotation and labanotation.

Another issue that comes to my mind is: For a LabanXML as well as a more generel movemenXML format, the theory must be clean. Followng what I read in the PhD(?) of Henner Drewes, it looks like there are many pitfals in systemizing Labanotation. There were a lot of attempts, and all failed

at a certain point.

So there is more to it than just wrapping XML around an existing notation.

I think there will possible be a need for also change the notation, so that it can be expressed in XML. (Feedback of the tools-of-the-tools (XML) on the tools (KIN/LN)).

And as was possible to read in this thread alrteady, from a notators perspective, there will never be a 100% translation between different notations... and I add: maybe not even within one notation...

Translating books (e.g. a novel) from one language to another also can never be done completely. Different languages create different world views ("realities").

And they are non-congruent (see P.K. Feyerabend ("Anything goes", "Wissenschaft als Kunst", ...) on non-congruency even within scientific concepts.)

(Nevertheless the attempt of computerized translation of notationsdso make sense. But the file-format issue adds a syntactical trouble to the sematic burden.)

So, all in all and in short:  I think the notation exchange issue has more impact on establishing movement notations (either of them) than just porting one of the used programs to iPad.  And I think a useable draft XML format for exchanging the notation is much more needed than any additional nifty features on a small-niche software.  (This of course depends on the perspective and the goals. But I remember,  some people mourned about movement notation is being not wide spread.)

But I wrote the same all to often. Like "same procedure as every year" it seems I better shut up and leave the list. Writing such answers  is very time consuming; and talking to a concrete wall without the influence  to move anything, is not very satisfying.

Ciao,

Oliver

---

 Lucy Venable, March 20

Dear LabanTalkers:

Let's stick to the question:  What new features would you like to see in LabanWriter 5?  We are limited to what we can work on which is only this program.  So the question really only applies to those who currently use LabanWriter.  When we have your requests,  we will reply & discuss them individually.

Thanks,

Lucy Venable

---

From Halloran, Gregory

From someone who was a student of Lucy when Labanwriter was first introduced, and someone who has not kept up with current applications, I would like to suggest that responses be kept to how to keep the current application usable.  I applaud and respect OSU for all their work including Lucy for their work in developing Labanwriter and support any constructive feedback on how to further develop the program.  Just my two cents.

Greg Halloran

---

From Katerina Elraheb

Dear Labantalkers,

I agree with Oliver that it would be great if LabanWriter is OpenSource or even better Free Software. What about having a version working on PC's (Windows, or Linux)? I believe opening the system will benefit all communities from notators and researchers in movement analysis, to researchers and developers of computer based systems and of course the usage of Labanotation. I 'm sure we have mentioned this http://www.dancenotation.org/news/Ohio_report/Ohioreport.pdf conference before which was held in 2004 (8 years ago!) and stressed the importance of a "lingua franca" for notating dance. To my opinion Labanotation offers an excellent point of reference in dance description and analysis, however, if people involved do not have an easy-access, tool e.g., LabanWriter to work, experiment, exchange files etc it becomes very complicated. 

BTW is there a kind of archive of .lw4 files which I can use for research purpose? Sorry if I'm asking about a something which was mentioned in the list before.

All the best!

Katerina

---

From Oliver, March 21

On Wed, Mar 21, 2012 at 01:53:49PM +0200, Katerina Elraheb wrote:

> Dear Labantalkers,

>

> I agree with Oliver that it would be great if LabanWriter is OpenSource or

> even better Free Software. What about having a version working on PC's

> (Windows, or Linux)? I believe opening the system will benefit all communities

> from notators and researchers in movement analysis, to researchers and

> developers of computer based systems and of course the usage of Labanotation.

Thanks for writing this.

> I 'm sure we have mentioned this

> http://www.dancenotation.org/news/Ohio_report/Ohioreport.pdf conference before

> which was held in 2004 (8 years ago!)

Just for the protocol:

I'm sure I mentioned these points some years before this report was written, and some of my sentences I frot to this list were going into that report nearly verbatim, without being quoted correctly.

> and stressed the importance of a "lingua

> franca" for notating dance. To my opinion Labanotation offers an excellent

> point of reference in dance description and analysis, however, if people

> involved do not have an easy-access, tool e.g., LabanWriter to work,

> experiment, exchange files etc it becomes very complicated. 

[...]

Without the possibility to exchange scores between different people using different computer systems, having only island-solutions, the programs will be used only by some people and other people use other programs. If they at least would have a common file format, this would be fine.

(I do not insist on XML btw; a well designed textformats also might make sense,  but then the parsing problem occurs... any software would need to implement certain parsers. So I think XML might be the easiest way of minimizing this initial software-issue (parsing problem). As Greg Shenaut has mentioned, MusicXML is wide spread. And it works fine. So I think this shows that  XML might be a good choice, and I understand, why he so urgently insists on XML since long time.)

Ciao,

Oliver

---

From Zack Brown, March 22

Oliver,

I understand your desire for a standard format such as XML for expressing Labanotation scores.

The problem is that Labanotation itself isn't amenable to that. It's not a technically rigorous system. A lot of the ideas expressible in notation rely on subtle poetic interpretations. Often the meaning of a piece of notation can only be understood by asking, "what *might* the author have meant when they wrote this?" And only by engaging in that kind of speculation are you able to come up with an interpretation of what the score is trying to say.

Labanotation as currently designed, is filled with vague ideas, contradictory meanings, context-dependent conditions, and has a high degree of circular dependency between many of its elements.

Because of these things, it's simply not amenable to anything more than the most simplistic of XML representations. Any substantial piece of notation would reach far beyond the ability of the XML DTD to represent it. And any XML DTD that *was* able to represent Labanotation fully, would be so complex that it would take a large team of people working day and night for years, just to design that DTD.

So, any sort of 'computer readable' format for Labanotation is just not a practical idea as things stand.

Be well,

Zack

---

From Oliver, March 22

Hello Zack,

thank you for joining a detailed discusion.

Let me answer between your paragraphs (as in typical internet quoting style).  (Looking at my answer with a monospace / nonproportional font will offer the magic of it.)

On Thu, Mar 22, 2012 at 09:04:22AM -0400, Zack Brown wrote:

> Oliver,

>

> I understand your desire for a standard format such as XML for

> expressing Labanotation scores.

OK, fine.

> The problem is that Labanotation itself isn't amenable to that.

Depends on how it will be realized, and how much of it's semantic you try to put into the format.

> It's not a technically rigorous system. A lot of the ideas expressible in

> notation rely on subtle poetic interpretations. Often the meaning of a

> piece of notation can only be understood by asking, "what *might* the

> author have meant when they wrote this?"

Is this a bug or a feature of the notation?

Comparing this with music notation: is there the same kind of problem?

Is this "what *might* the author have meant when they wrote this?" problem a problem of artists interpretation or of ambiguity/illegibility of the notation?

If it's an artist's interpretation topic, then it should also occur in music notation. But if you look at the MusicXML (as Greg pointed to aagain and again), this seems to work quite well.

> And only by engaging in that > kind of speculation are you able to come up with an interpretation

> of what the score is trying to say.

>

> Labanotation as currently designed, is filled with vague ideas,

> contradictory meanings, context-dependent conditions, and has a high

> degree of circular dependency between many of its elements.

Look: there is a notation. And it might have some ambiguity. But the ambiguity (more than one interpretation) is there, even the notation is unchanged.

Say you have a notation printed (or written) on paper. You look at the same notation one day and the next, and it has different meaning on the other day. Or two persons look at the same notation, and see different meanings even at the same time.

But the notation on paper has not changed in the meanwhile.

These interpretations are idnividual. They come from the mind of a person with certain experiences (movement experiences as well as experiences in general).

Even the notated piece did not changed.

So, what the computer has to offer is just the possibility to create and reproduce the notation, so that it looks the same if you print it today or tomorrow.

LabanWriter solved this problem, by just storing the locations of the symbols on the staff.

>From a Laban theory perspective this might look weak.

But at least it works. People can use Labanwriter and it helps them in daily work. Even the underlying representation is just a bunch of symbols.

It might be much better from a Laban theorists person to have a more conceptual driven dataformat. And I agree with that.

But as you stated: you can't do that, because the ambiguity must stay there (just because the notation is as it is today, and throwing those ambiguity away would mean to break off some notational possibilities).

I agree here too.

And this is not a contradiction.

The Lanban notation seems to have some ambiguities built in, which maybe should be thrown away. Regarding Henner drewes discussion of Labanotation vs. Kinetography Laban, the later seem to be more strict and logic and easier to adapt in a compurterized (non-ambigous) way. And the former is rather adapted in a more pragmatical way: "We need a symbol for xyz, what wynbol should we invent for it?"

That is the point, which I mentioned as: not only the computer-software must be adapted to the notation; maybe the notatuon must be adapted to become easier compuzterized.

But this has the risk of making the notation not only strict,

but also becoming "dead" / less expressive.

But there is a solution to it.

> Because of these things, it's simply not amenable to anything more

> than the most simplistic of XML representations. Any substantial piece

> of notation would reach far beyond the ability of the XML DTD to

> represent it.

You can use XML-like data format without a DTD btw.

> And any XML DTD that *was* able to represent

> Labanotation fully, would be so complex that it would take a large

> team of people working day and night for years, just to design that

> DTD.

I agree here too.

But this is not an argument against such a format. It depends on what the format represents.

See below.

> So, any sort of 'computer readable' format for Labanotation is just

> not a practical idea as things stand.

Here I disagree.

See: there are two positions:

   1) Just represent the poitions of the graphical symbols of a notatoion      inside the computer.

   2) Represent the meaning of a notation inside the computer.

The first position is, what is done in LabanWriter. It's pragmatic and works.

The second position is something that people think might be a vision worth working for.

But let me add: if with "meaning" is meant, what the notation should express and how people has to respond to a a movement that is described in a certain notation, I can just say: hey, how people respond to a piece of dance or other movement is so individual that it never can be expressed in a computerized way.

Nevertheless some concepts might be expressed in a computerized way. But say, that the research is not advanced enough to represent these movement concepts, then there muzst be more reesrach to clear these points.

But the above mentioned distinction is mixing things, if the representation of the symbols as graphical symbols is bound to a non-XML fileformat and the meaning-representation is bound to a XML-dataformat.

But these things do not necessarily need to be bound in this way.

people think like this:

  Symbol-representation  -> non-XML

  Meaning-representation -> XML

This distinction is not correct.

  * You could also use XML for just plain graphical symbol representation.

  * And you will not be able to express the meaning with XML

The distinction of using XML vs using non-XML representation has nothing to do with WHAT is expressed with the one or the other format.

Using XML has just one advantage here: to have the data format easily read into the computer (scanning/parsing).

It says nothing about what is represented by that XML stuff.

You could use XML for just plain symbol representation.

If you may ask: hey, why using XML then, if it adds no new things... and just does the same as for example LabanWriter does at the moment?

Then I answer: It's "just" the possibility to easier read that format into a software.

But this advantage does make sense regarding exchangability.

At the moment, LabanWriter just saves the symbols and their positions in a file. LabanWriter does not attempt to gain an "understanding" or  interpretation" of a score.

It's just a tool to notate something.

But it uses a data format, that needs everybody who wants to read the LabanWriter files, to program a parser for it.

this means: for each person who wants to read LabanWriter notation to do the same work.

If the same kind of representation-of-symbols would just be converted to a XML-based format there will be no advantage regarding notational concepts.

But it would be much easier for people to just read in LabanWriter files and play around with it.

Of course it would be fine if the symbols wouzld be represented as not only graphical-symbol names ("shape=rectangle;color=black") but as their

Notational names (e.g. "direction-down").

So this would be a little more than just graphical symbols - it would be notational symbols. (Hmhh, LabanWriter may already does this.)

And the representation would make sens to have it in symbolic NAMES (like "direction-down",instead of a number ("23").

So, what is going wrong in the whole discussion is intermixing syntactical and semantical part of the problem.

The XML-issue solves the syntactical problem of readin in (scanning/parsing) a file. The semantical problem of interpreting it is up to the software (or the personwho uses it, if it's about "meaning").

Solving the exchangability problem (syntax of the dataformat) does not solvce the interpretation probem on the notational level.

But it offers possibilities to better exchange.

And even that small advantage IMHO is worth to be implemented.

And the XML/DTD for that might be comparingly easy.

You don't need to represent the meaning of certain combinations of symbols. (Or not in the beginning. This cna be done during the years.)

But it's easier to understand

<score>

  <symbol class="direction" value="up", start="12.4", end="12.8">

  </symbol>

  <symbol class="limb" value="right-foot", posx="8.4" posy="4.6" size=1.2>

  </symbol>

</score>

compared to

1 23 44 656 33 77 33 22

2 33 677 33 55 44 677 55

2 35 545 3 435 3 32 3

The former can be read by humans as well as xml-parsers and the latter can only be read by a certain software that has implemented that certain scanner/parser and the programmer who invented this (or used much time to understand it).

A different thing would be to have even more meaningful higher-level concepts of a notation be inside the format. Even is this might be interesting, I also think this is not possible to solve soon. I think the theory is not advanced enough to allow this.

But that deos NOT mean to insist on a format like

3 65 3 6 45 54 45 45

4 4 7 3  5 65 4 32

4 7 6  8  44  77 5

compared to something like

<score>

  <symbol class="direction" value="forward-down", start="32.5", end="34.8">  </symbol>

  <symbol class="limb" value="left-hand-finger-2", posx="8.4" posy="4.6",

size=2.2>

  </symbol>

  <symbol class="bodypattern" value="core-distal", posx="8.4" posy="4.6",

size=2.5>

  </symbol>

</score>

In either case the interpretation of the meaning of what the choreographer wanted to say us, is in the eye of the beholder.

But that has nothing to do with the dataformat issue.

Ciao,

Oliver

 

---

Oliver,  March 21

Hello,

Let me add another proposal.

If XML seems to create too much confusion, CSV-format would also be something that could help to solve the compatibility issue.

There are CSV-parsers in many programs, and there are many programmer-libraries to just read in a CSV-file.

With CSV as format, you could even use Excel to read in Labanwriter files and do some analysis with it.

Of course the number-coding of LabanWriter files should then use symbolic names instead, so that people who look at the notation from within e.g. Excel, can look for symbolic names instead of handling number-encoded staff.

Maybe this is a compromise that is even better than XML, at least at the current stage.

CSV also can be read by humans as well as machines.

Some care should be used with that of course, so that the format is designed. I also already saw ugly designed CSV output. But designed with some care, they even for human eye look nice and can be read like a table.

If XML or CSV will be used is not that much of a problem.... both would be a step forward compared to what is used at the moment.

At least I have not heard of a LabanWriter-parser inside Excel, Word or OpenOffice. But CSV parsers are there, and so widespread, that many other programs offer these too.

(I think thats even better supported than XML.)

Ciao,

Oliver

---

From Brenton Cheng, March 21

I agree 100% with what Oliver writes below.

I think two key distinctions are made:

1) Whatever ambiguities there are in how well Labanotation captures the lived movement event, Labanotation itself *can* be captured in a computer-readable format such as XML.

2) In using a computer format to capture Labanotation, there is a choice about whether to include Labanotation's *structure* within the format -- e.g. indicating that movements X and Y are within the same phrase bow -- or whether the format just represents the graphical layout of objects -- e.g. movement X should be placed 3 units up, movement Y 4 units up, and a phrase bow should go from unit 3 until unit 4. The former is ideal; the latter is acceptable (and better than nothing).

I would also agree that, for the coming day when we all have more time/resources toward building better tools on different platforms, it would be important to have a common medium of exchange, i.e. a common file format.

Last point, I am curious about Motif's representation, as distinct from Labanotation's. Though many symbols are similar, its needs are very different.

Cheers,

Brenton

---

From Oliver, March 23

Hello Brenton,

Thanks for your comment.

Let me add: A notation author could - if that feature is supported by the software -use grouping of symbols explicitly.

Some graphics programs do this and call it grouping/ungrouping.

Is there a reason why this should be possible with any graphics, but not with graphics that represent Labanotaton?

Strange kind of logic: the common case works in general, the special case of the common one does not?

Or look, how asian language is typed into computers. There will pop up selection menues with the right kanji, if you enter the romaji... why should this work in asian languages, but not with Labanotation? I see there no reason.

But discussing this again and again makes no sense.  It will just not be implemented.

Movement notation is so much of a niche and will stay as niche. It's a useful tool for a nearly vanishing amount of people.

So... why bother?

Evolution will eradicate movement notation as a tool in use... :->

We are eyewitnesses of a dying species.

Motion Capturing will survive. :P

Ciao,

Oliver

---

From Oliver, March 23

Hello Brenton,

thanks for your comment.

Let me add: A notation author could - if that feature is supported by the software use grouping of symbols explicitly.

Some graphics programs do this and call it grouping/ungrouping.

Is there a reason why this should be possible with any graphics, but not with graphics that represent Labanotaton?

Strange kind of logic: the common case works in general, the special case of the common one does not?

Or look, how asian language is typed into computers. There will pop up selection menues with the right kanji, if you enter the romaji... why should this work in asian languages, but not with Labanotation? I see there no reason.

But discussing this again and again makes no sense. It will just not be implemented.

Movement notation is so much of a niche and will stay as niche. It's a useful tool for a nearly vanishing amount of people. So... why bother?

Evolution will eradicate movement notation as a tool in use... :-> We are eyewitnesses of a dying species.

Motion Capturing will survive. :P

Ciao,

Oliver

---

From Rachelle P Tsachor, March 23

First, thanks for the program, which I use often, and for asking what we need.

1)  A more reliable way to transfer images generated in Labanwriter to other programs.

Save As and Export often tell me that there is too much data to export to PICT or JPEG.

I often need to create motifs in Laban writer and place them as a picture in other programs,such as Word or Powerpoint, but often I spend more time struggling against the program limitations of transferring data,  than actually using the program productively.

2)  I would like to be able to turn off the feature that assigns symbols to a staff, because I often just want to generate symbols or short motifs off a staff, and it seems that the first symbols I place on a page are always associated with a staff, which makes it hard to then copy and paste them or save them as an image.

3)  More motif symbols, and a way to write horizontal motif easily, not associated with a vertical staff.

4)  On my computer, the font sometimes switches, and isn't checked on the font menu, so it is hard for me to know which font something is in—I often write words next to symbols and would like to have better control of fonts.

Thanks again.

Rachelle

---

From Oliver, March 23 

Hello,

you have created some workarounds on the limitations of Labanwriter.

If you just want to use the symbols for yourself, you can get them as jpeg-files in a zip file. Some years ago (2008) I converted the Labanwriter symbols to jpeg files.

You can download them here:

  http://www.first.in-berlin.de/laban-pics/laban-pics.zip

Or if you wish to look at them via webpage,  see here:

  http://www.first.in-berlin.de/laban-pics/index.html

Hope that helps.

Ciao,

Oliver