[linux-l] Sprache für Laban-Choreographien (was: Grammar Design)

[Oliver Bandel]

Moin, 


On Mon, Sep 19, 2005 at 02:49:12PM +0200, Volker Grabsch wrote:
> On Mon, Sep 19, 2005 at 12:45:15PM +0200, Oliver Bandel wrote:
> > Also XML: Es soll mal eine DTD für Laban-Symbole entwickelt werden.
> > Diese existiert noch nicht. Selbst die Spezis des Laban-Fachgebiets
> > haben sich da noch nichts entworfen, es gibt allenfalls die Idee,
> > diese DTD zu entwickeln.
> 
> Du hast diese Buchstaben-Notation für einzelne Laban-Zeichen. Die
> ist doch ein sehr guter Ansatz. Brauchst du für die Beschreibung
> einzelner Symbole etwa noch mehr?

Die Buchstabenkürzel dienen nur zur Kennzeichnung der Richtungssymbole.
Diese werden in der Laban Movement Analysis benutzt. In der Weise, wie
vom labscalgen genutzt.
Textsatz plus Symbole in der selben Weise gesetzt, wie Fließtext.

Es gibt aber auch neben der Laban movement Analysis die Laban-Notation (siehe die Links).
Dort gibt es sehr viele weitere Symbole. Ausserdem werden diese entsprechend
des Zeitverlaufs einer Bewegung vertikal gesetzt, von unten nach oben bei
vorwärtslaufender Zeitachse.
Die einzelnen Spalten sind verschiedene Körperregionen.
Ausserdem gibt es für bestimmte Körperteile auch noch ergänzend Symbole.
Dann gibt es z.B. Symbole für Drehungen, für Körperrichtungen im Raume,
für die drei Bezugssysteme, die benutzt werden können usw.

Sinnvoll ist IMHO, eine Beschreibung zu benutzen, die mehr aussagt
als nur "setze ein Rechteck mit dieser Schraffur an jenen Ort" und daß man
besser eine Beschreibungsform hat, die sagt: "move left leg to Deep-Right-Forward",
"pivote turn, ending with body-front looking at formerly left direction",
"jump from left foot to right foot", usw.

Da die meisten Symbole kontextsensitiv genutzt werden können....

...oh, oh.

Hatte ich nicht geschrieben, daß die Labanotator-Ausblindung ein paar Jahre dauert?

Die DTD für die ausführliche Labanotation sollen die Spezies entwickeln.
Die werden dafür auch bezahlt (sofern die Gelder bekommen, sonst bleibt das projekt liegen).
Aber die kennen sich mit der ausf. Notation am besten aus.


Neben der ausf. Notation gibt es auch noch eine vereinfachte, das sogenannte Motif Writing.
Da werden nicht alle Bewegungen detailiert aufgeschrieben, sondern nur das Bewegungsmotiv.

Was mir letztlich vorschwbt ist, die Konvertierung zwischen den verschgiedenen
Notationen zu erlauben.


Es gibt auch noch weitere Bewegungs-/Tanznotationssysteme, von denen ein paar noch geläufig sind.
Es gibt noch die Benesh-Notation (eine grafische Notation, die auch die Körperposen auf einem
Liniensystem (ähnlich dem der Musiknoten) einsetzt; häufig im Kontext des klass. Balletts eingesetzt).
Es gibt dann noch die Eshkol-Wachmann-Notation. Diese ist eine allg. Bewegungsnotation, die mit Tabellen
arbeitet. Man kann sie auf n Gliedmassen erweitern und sie wurde z.B. auch für Insektenforschung eingesetzt,
oder auch Robotik.

Konvertieren zwischen diesen Bewegungssystemen zu ermöglichen, das wäre super-genial.

Aber es sind teils grundlegend andere Konzepte der Beschreibung und eine Konvertierung ist nur
bedingt möglich.
Aber wenn das eben auch nur verlustbehaftet geht, wäre das Ermöglichen einer solchen Konvertierung
dennoch ein genialer Fortschritt.

Wenn man das ganze dann noch in bezug setzt zu Differentialgleichungen / physikalischer Bewegungsbeschreibung,
dann ist man ganz schnell auch bei Film-Animation usw.

Jedenfalls wäre es sinnvoll, wenn man eine DTD nutzt, daß die nicht nur das
macht, was man auh anders haben kann, wenn man einfach nur Grafikobjekte auf einem
papier positioniert.

Es geht doch gerade um die konzeptuelle Beschreibung von Bewegung!

Das ist ein dauernd währender Prozess. Da gibt es noch viel Diskussionsbedarf.
Deswegen sollten da auch Leute ran, die schon als Notatoren gearbeitet haben.

Jedenfalls ist das, was ich da machte, ein Subset der Symbole und auch nur in einer
Anwendung, die in diesem Falle einfach nur das setzen der Symbole in einer Reihe
erfordert.

Da es für so etwas aber auch noch keine Software gibt, war das für die Leute aus der
Laban-Ecke sicherlich ein erster Knaller... :)

Ansonsten wurschteln die mit Word und LabanWriter herum.
und versuchen irgendwie, Symbole von einer Software zur anderen zu exportieren.

Meine Mails auf den entsprechenden Listen, man solle doch mal einen Font entwickeln
verhallten ohne Ergebnisse.

Immerhin war der Entwickler vom LabanWriter so nett, seine Symbole als TTF
zu exportieren. aber die Symbole haben woghl nur Bildschirmauflösung, was
das ganze nur bedingt einsetzbar macht.


Größter Mangel besteht wohl da an der Finanzierung.
Aber ich glaube auch nicht, daß word-Nutzer unbedingt von sich aus
Markup-Apologeten sind....



> 
> > Da geht es um extrem komplexe Dinge und das kann noch Jahre dauern,
> > bis da was entwickelt wird. Es gibt auch sehr viel mehr Symbole
> > als bloß die Richtungssymbole.
> 
> Geht es nur um mehr Symbole?

mehr Symbole, anderes Setzen der Syymbole,
und IMHO sollte die DTD nicht die Symbole, sondern deren Bedeutung reflektieren.

In wieweit das *überhaupt* funktioniert, weiß ich nicht.
Das wissen auch die Spezis da nicht.
Da haben schon einige Versucht die Nüsse zu knacken. :)

Mal schaun. :)


> 
> Bisher habe ich nur einen Haufen von Symbolen gesehen, die aneinander
> gereiht werden. Folglich lässt sich dein Problem, wiegesagt, in zwei
> übersichtliche Teilprobleme zerlegen:
> 
> 1) Laban-Symbole geeignet beschreiben und rendern
> 2) Laban-Symbole anordnen (Choreographien)

Es geht bei der ausf. Notation (und beim motif-Writing) aber um eine
von unten nach oben laufende Notation, bei der nach rechts und links jeweils die
Symbole gestzt werden. Allgemeine, wie die Richtungssymbole, aber auch
speziellere, wie beispielsweise Symbole, die bestimmte Körperteile anzeigen/bedeuten.


> 
> Das 1) Problem hast du weitestgehend gelöst mit einem IMHO sehr
> geeigneten Ansatz.

Ich habe das problem gelöst für die horizontale Notation.
Man kann die Skalen auch vertikal schreiben.
Aber Postscript sieht dies ja glücklicherweise als Möglichkeit
for. Neben "sho" gibt es auch "ashow" und "kshow" und so.
Einer von diesen Operatoren kann auch senkrecht setzen,
so, wie man es z.B. auch für japanische Schriftzeichen braucht.

(Ein weiteres Projekt von mir: gib japanische Schrift in Romaji ein und bekomme
die Symbole in Hiragana/Katakana/Kanji als *.eps)


Die Richtungssymbole mit diesem Kürzeln zu versehen, das ist zwar (IMHO) naheliegend,
wenn man mit Sachen wie Enums in C oder Sum-types in OCaml arbeitet.
Dennoch habe ich mich bei der Benutzung dieser Symbole an die Literatur gehalten.
Da gibt es ein Buh zur Laban Movement Anaylsis, wo die genau DIESE Buchstaben genommen haben.
Darauf beziehe ich mich. (Hmhhhh, könnte ich auf meinen Seiten noch erwähnen).
In anderer Literatur nehemn die z.B. statt "H" für High und "D" für Deep eher
"U" für Up und  "L" für Low oder noch andere Abkürzungen. 


> Eine "neue Sprache", also die Buchstabenküzel,
> ist IMHO gerechtfertigt und eine gute Idee.

IMHO aus Programmierersicht naheliegend, beziehe mich aber dennoch auf
Kürzel, die in der Literatur benutzt werden (wie gesagt aber nicht einheitlich).


> Vorallem, weil es offenbar
> noch keine standardisierte "eintippbare" Beschreibung dieser Symbole
> gibt.

Bisher tippen die Leute nicht ihre Skalen als Texte, sondern klicken herum.

So gesehen ist mein Ansatz was durchaus neues.



> Eine Alternative wäre ein neuer Font.

Ich habe einen Font definiert.
Hatte ich doch in der anderen Antwort-Mail geschrieben.
Ach so... die habe ich ja erst nachts los geschickt...
...konntest Du ja noch garnicht lesen.



> 
> Das 2) Problem hingegen ist, nüchtern betrachtet, einfach bloß Textsatz.

Nein, nur wenn man die horizontale Schreibweise der einfachen Notation
der Richtunbgssymbole für die Skalen nimmt.

Das war bisher auch nur der Aufgabenzweck des labscalgen.
Aber weitergehendere Projekte hatte ich eigentlich schon vor...


> Und du machst nichtmal komplexe Dinge. Wiederkehrende Musten durch
> Variablen abkürzen, Überschriften, Zeilenumbrüche, das sind alles
> längst gelöste Probleme. Hier eine neue Sprache zu erfinden halte ich
> für groben Unfug. Alles, was es gibt (TeX, LaTeX, ConTeXt, Lout, ...)
> ist in *diesem* Bereich sehr einfach und anwenderfreundlich, und hat
> weitere Vorteile. Das habe ich in der letzten Mail an zahlreichen
> Beispielen belegt.

Man kann Word-Nutzer, die sich für Computer-NICHT-Kenner halten, teils
schon weit über 60 sind,  nicht so einfach davon überzeugen, daß sie ihre
Texte zukünftig nicht tippen, sondern programmieren sollen.

Du vergißt diese psychologische Hemmschwelle.

Den Leuten darf man nicht sagen, daß sie programmieren, selbst wenn sie es tun.
Erst, wenn sie es bereits erfolgreich getan haben kann man sagen, daß sie aber
ganz schön eifrige Programmierer sind. ;-)


Der Rest der Mail erübrigt sich damit dann wohl...

 
[...]
> Außerdem hast du meine Frage nicht beantwortet, ich stelle sie nun
> zum zweiten Mal: Wie erzeugst du diese Symbole? Was hältst du von einem
> Font?


Es hat ganz einfach seeeeeeehr lange gedauert, af Deine seeeehr lange Mail
zu antworten. Habe das heute in drei Etappen erledigt.

> 
> 
> [DTD für Laban]
> > Mit irgendwas muß man aber anfangen, und da ich keine vorhandene
> > DTD habe, und da diese auch von den Labannotations-Spezis entwickelt
> > werden sollte, nützt mir auch ein XML-Parser erst mal nix,
> 
> Ich verstehe leider immer noch nicht, wozu dieses XML-Format gut sein
> soll.

Ich dachte, DU bist der XML-Apologet. ;-)

Aber: es geht dann um die ausführliche Notation, nicht nur das
Schreiben/zeichnen von Skalen in einem Text.

BTW: Wenn man einen Laban-Score hat, hat man u.U. neben der von unten nach
oben laufenden Bewegungsnotation noch Extra-bereiche auf dem Blatt,
wo die Floor-Plans drauf sind. Man kann das dann auch noch ergänzen um
Musik-Noten, die man entweder irgendwo noch auf dem Papier unter bringt, oder
die man grafisch synchron zu der Bewegung notiert, wobei dann natürlich die
Musik-Noten um 90 Grad gegen den Uhrzeigersinn rotert werden und dann
zeitlich mit dem Bewegungs-score übereinstimmen müssen.

So, und da wäre also der Unterabschnitt der Erstellung von Musiknoten-Satz.
Der ist für sich allein übrigens auch nicht trivial, und wäre da nur ein Subsystem,
das in den Laban-Score mit rein müsste.

Noch Fragen?  ;-)



> 
> Wenn ihr eine eigene XML-Sprache für Laban-Symbole haben wollt: Viel
> zu umständlich. Deine Buchstaben-Notation reicht doch völlig aus, oder
> übersehe ich da was?

s.o.


Es wäre natürlich gut, wenn auch weitere, nicht nur die Richtungssymbole,
in ein Textsystem integriert werden könnten.
Die Antriebs-Symbole (Effort-Graph) hatte ich mal mit pstricks in LaTeX
eingebunden. War nicht perfekt, aber die Ergebnisse waren ganz brauchbar.
Aber sowas dann zu tippen im Dokument... da krigt man auch fast 'ne macke!



[...]
> Welcher Art sind eigentlich die "komplizierten" Probleme, die bisher
> die Definition einer Laban-DTD vereitelt haben?

s.o.

Das ganze Forschungsgebiet ist noch stark in der Wandlung.



[...]
> Aber falls es wirklich nötig wird, löst deine eigene Syntax doch
> keine Probleme, die XML nicht ebenfalls lösen würde.

Naja, wenn man auch Funktionen integrieren kann, dann geht auch XML.
Ich dachte vorher, das wäre nicht XML-konform und hatte was XML-ähnliches
selber entwickelt, und dann Funktionen-Funktionalität dazu implementiert.
Daß man aber auch sowas mit XML bauen kann, meintest Du ja, würde gehen.
Also kann XML doch in Frage kommen.
(ein bischen was wie re-inventing XML wäre es sozusagen geworden ;-))


> Von daher
> verstehe ich nicht, wieso du keine eigene Laban-DTD beginnst, das
> wäre immer noch schneller, produktiver und für die Allgemeinheit
> nützlicher, als "yet another ... language".


Sehr komplexes Gebiet.

Ich will auch nicht derjenige Sein, der (auch noch unbezahlt)
die Irrwege geht, aus deren Fehlern die anderen Leute, die auch noch
dafür bezahlt werden, lernen, um dann ihre Merits abzugreifen.
Hinterher kann ich dann noch froh sein, wenn ich die Software benutzen darf?

Nö.

Dann sollen die Spezis das mal machen.

Ciao,
   Oliver