What new features would you like to see in LabanWriter 5?
By David Ralley et al.
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:
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.
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,
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:
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...
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
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
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
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:
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
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
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:
Or if you wish to look at
them via webpage, see here:
Hope that helps.
Ciao,
Oliver
Posts
