[linux-l] Labanotation-Projekt (was: Grammar Design)

Oliver Bandel oliver at first.in-berlin.de
Sa Sep 24 16:43:57 CEST 2005


On Fri, Sep 23, 2005 at 08:41:37PM +0200, Volker Grabsch wrote:
> On Thu, Sep 22, 2005 at 06:32:42PM +0200, Oliver Bandel wrote:
> > On Thu, Sep 22, 2005 at 02:49:34PM +0200, Volker Grabsch wrote:
> > > Mit
> > > allen Features, die eine Programmiersprache bietet, inkl. Aufrufen
> > > von externen Filtern oder Berechnen von 100 Nachkommastellen von PI.
> > > Aus dieser Sicht heraus wäre nämlich Python eine gute Wahl gewesen.
> > > Und natürlich kannst du dann die Labanotation-Sachen nicht mehr als
> > > Dokumente betrachten, sondern musst sie wie Programme behandeln, mit
> > > allen Risiken, die das Starten von fremden Programmen nunmal beinhaltet.
> > 
> > Eben, das ist erstens zu viel, was nicht gebraucht wird, und zu
> > riskant. Und was ich brauche, muß ich eh implementieren;
> 
> Also grundsätzlich erstmal: Ja und Nein.
> 
> Ja, du solltest das XML-Format von deinem Programm parsen lassen, und
> Dinge wie "Makros" schnell selbst implementieren.
[...]

> > > Scripting-fähigkeiten,
> > 
> > Doch.
> > 
> > Wenn ich nicht nur eine Skala habe, sondern mehrere, und für alle
> > (als Liste der Skalen) eine flip-RL Operation oder ähnliches durchführen will,
> > dann ist das schon einiges notwendig an Sprach-Möglichkeiten.
> 
> Achso? Erklär mal bitte am Beispiel, und für welchen praktischen Zweck
> das gut ist. Das läuft IMHO nicht auf Foreach-Scheifen, sondern auf
> Filter hinaus, also Attribute bzw. Operationen eines höheren Knotens
> des Dokument-Baums. Aber werd erstmal konkret.

Die Dokumenten-generierung ist nur ein Teil.
Mir schwebt eigentlich ein Notations-Analyzer vor.



> 
> > Mal schauen, viell. baue ich da selber was zusammen :)
> > Eigene JavScript-Engine. Wieß ich aber nicht, ob ich dazu
> > die Musse habe. Jednfalls könnte man damit nen super-krassen
> > Web-Robot bauen. :)
> 
> Nee, so weit würde ich nicht gehen. Du brauchst offenbar kein
> JavaScript, also implementiere auch kein ganzes. Wenn du's brauchst, dann
> implementiere es nicht, sondern nimm es einfach. :-)


Ach weißt Du, ich habe mir über das teil schon oft und viele Gedanken gemacht.

Du kommst mir immer wieder mit Arroganz-Vorwürfen, aber es ist von Dir sehr
arrogant, mir Sachen als die unbedingte Neuheit aufschwatzen zu wollen, die
ich eh schon erwägt hatte.
Du meinst vielleicht, mir hier neue Sachen zu empfehlen und meinst immer,
mir irgendwelche Ratschläge geben zu müssen.
Deine Mathematiker-Arroganz hast Du ja schon ein paar mal heraus hängen lassen.

Weißt Du, wenn ich eine Frage habe und gerne einen Hinweis bekommen möchte, finde
ich es ja nett, daß die Leute auf der Liste einem gerne helfen.

Aber wenn Du meinst, mein Labanprojekt planen zu müssen, und immer wenn ich eine
Sache preisgebe, dann das ganze als blödsinnig darzustelen, doch letztlich
kommst Du dann einige mails später mit der selben Empfehlung, die ich als Idee hatte
und die Du erst mal abgelehnt hast, dann finde ich das echt nervig.



[...]
> Da wäre ich vorsichtig. :-)
> 
> Ich finde, du solltest nicht in Richtung Scriptsprache denken, sondern
> mehr in Richtung Dokumentensprache. Ich kann mir einfach nicht
> vorstellen, was ein Labannotator mit ner Scriptsprache besser könnte.

Woher nimmst Du diese Empfehlung?

Aus dem bischen, was Du da im netz als Beispiel gesehen hast schliesst Du,
daß Du das gesamte Vorhaben, das mir vorschwebt, bereits zu kennen.

Das ist aber nur EIN kleiner Ausschnitt!

Was später mal alles dabei sein soll:
- Eingabe der Notation mit einer speziellen Sprache (DSL)
- Eingabe der Notation mit GUI
- Einlesen einer Laban-XML
- Analysieren von Notationen
- Echtzeit 3D-Animation von Notationen
- Eingabe von Tanzbewegungen via 3D-Interfdace => Notation wird daraus generiert!!!
- Ausgeben der Notation auf Postscript-/PDF-Basis (auch auf >> DIN A4)
- ... vieles weiteres noch :)

Du kennst nur ein winziges bischen.

Es gibt ein Grob-Konzept und irgendwo habe ich noch die OpenGL-Sourcen
rum liegen. Das war damals noch in C.
Wird später alles OCaml werden.
lex/yacc ist nicht nur für die DSL gedacht, sondern u.a. auch für das
analysieren einer Low-Level Zwischensprache, die die Ausgaben des
Analysators via Netz zum Anlysator transportiert => remote-bedienung
ist nicht nur geplant, sondern war ansatzweise schon implementiert.

usw.


Und Du kommst mir mit Vorschlägen, die aus einem kleinen Subset dessen,
was geplant ist, exrapolieren auf das Gesamtsystem.

So kommt nur Murks bei herum.

Vielleicht kannste einfach mal die Ideen andrer Leute auch als
durchdacht ansehen. Ansonsten trifft Dein Arroganzvorwurf eher
auf Dich selbst zu.


[...]
> > Bleibt wohl auch nur: ausprobieren.
> 
> Transparenz ist wichtig. Was hast du gegen LaTeX & Co. ?  Angenommen, du
> hättest die Laban-Symbole als Font. Wäre dann LaTeX nicht die
> angemessenste Ausgabesprache für dein Programm?

Nein.

[...]
> > Vielleicht sollte ich erst mal mit MusicXML herum probieren und schauen,
> > was man damit so alles machen kann.
> > Als Vorstufe für Laban-XML.
> 
> Ich wüsste gern, wo dein Problem ist.

Das habe ich bereits mehrfach erwähnt!

Das Hauptproblem liegt daran, daß selbst diekenner der Notation
Probleme damit haben, die Sachen strukturiert zu erklären, oder
zuzmindest in einer Sprache, die andere Leute (z.B. Programmierer)
verstehen können. ;-)

IMHO sind auch manche Konzepte der Notation sehr fuzzy.

Es gab bereits Leute, die versucht haben, LN mal im Computer zu implementieren.
Es gab immer irgendwelche Sachen, die sich nicht korrekt realisiern liessen.
Man kann auch eine Bewegug auf verschiedene Weisen notieren.
Und alle diese Vorgehensweisen können auch sinnvoll sein.
die Notation anders zu benutzen kann an der dahinter liegenden Intention
liegen. Dies ist möglicherweise prinzipiell nicht serialisierbar.
Aber genau dieses serialisieren muß man machen, wenn man die Notation
per Computer nutzen will.
Es geht hier nicht nur um SQL-Datenbank für's ablegen irgendwelcher
Zahlendaten, sondern um menschlich interpretierte Dinge, die mathematisch
nicht erfassbar sind, die aber mit einer Symbolsprache dargestellt werden sollem.
=> Gödelts nun bei Dir?



> Du solltest doch kein Problem
> haben, einfach mal eine DTD zu produzieren.

Was das Erstellen einer DTD angeht, müsste ich mich da noch
einlesen. habe ich noch nicht gemacht.
Das ist aber sicherlich das KLEINSTE Problem.

Das größte ist, die DTD dann möglichst sinnvoll hin zu bekommen.

Obwohl Labannotation als allgemeingültige Notation für
menschliche Bewegung angetreten ist, gibt es zum Beispiel
eine kulturell unterschiedliche Sichtweise/Interpretation
von Bewegung und daher wird es auch immer irgendwelche Fuzzyness
in diesem Bereich geben.
Man kann zwar schärfe zu erreichen versuchen, aber wer sich die
Rinde und Wurzeln und Blätter  Bäume sehr detailliert ansieht,
sieht den Wald nicht mehr. Wer den ganzen Wald sieht, kann vielleicht
die Blätter nicht mehr auflösen...

Wenn nichtmal die Notationskenner die serialisierung hin bekommen
haben, ...




> Überlege dir eine Syntax für
> die Symbole (hab ich dir ja demonstriert), und dann fasse sie erstmal
> nur zu Zeilen zusammen, und schon bist du auf dem Stand des
> Laban-Scale-Generators.

Du verstehst nicht: Wenn ich mir mit meinen rudimentären Grundkenntnissen
der LN eine solche DTD entwerfe, wird es der Sache möglicherweise nicht gerecht.

DAS ist IMHO das Hauptproblem. Deswegen habe ich dieses Projekt eigentlich
erst mal zurück gestellt; vielleicht bis zu dem zeitpunkt, wo ich doch
noch die Notatoren-Ausbildung mache.
Leuten, die diese machen wird immer wieder gesagt: Ohne sich selbst zu bewegen und
in Tanzklassen die sachen auch nachzuvollziehen/mitzuvollziehen, KANN die Bedeutung
nicht klar werden. (die verschiedenen Bedeutungen)

Lassen wir dies mal so stehen!


[...]
> Was spricht gegen die \begin{picture} - Umgebung?
> Wie schon oben gefragt: Wenn der Font da ist, biete dir LaTeX alles was
> du braucht, oder?

Vergiß diesen Schmus!
Warum nehmen wohl so viele Leute trotz LaTeX's picture-Umgebung
doch externe Tools (XFig, metapost, etc.)?!

So lange LaTeX kein natives Grafikinterface hat, das wirklich leistungsfähig ist,
solange kann man damit nicht wirklich ernsthaft arbeiten.

Man könnte allenfalls einen Grafik-Preprozessor erstellen, der
dann als Ausgabecode LaTeX's picture-Anweisungen erzeugt.
Aber dann kann man auch gleich ein *.eps erzeugen und \includegraphics
nehmen.
Macht mehr Sinn.


[...]
> > Ich will niemandem zumuten, sich direkt mit SVG beschäftigen zu müssen.
> > Statt dessen High-Level Kommandos, wie z.B.: "move right leg up to 90 degrees".
> > Dies könnte dann in ein XML-Format konvertiert werden.
> > Ansonsten tippt man sich ja dämlich, wenn man die ganzen Tags
> > schreibt.
> 
> Meine Rede! Genau das hab ich dir doch empfohlen.

Ach, wirklich?
Bisher hast Du fast immer zu XML geraten.
Sagte ich eigene Sprache, kam immer gleich: laß es.

Aber vielleicht meintest Du ja nur die Syntax.


[...]
> Ich hoffe, diesen Vorschlag ignorierst du nicht,

Du hats mir vorgeschlagen, was ich eh vor hatte.

Was willst Du eigentlich mit dieser Strategie erreichen?
Daß man Deinen Namen preiset?

Willst Du den Helfer-Orden bekommen?


[...]
> Genauso hätten wir auch schon längst an dem XML-Format basteln können,
> wenn du meine XML-Beispiele verbessert hättest, statt sie in der Anwort
> wegzulöschen.

Es gibt auch "high-level" Bewegungskonzepte.
Wenn man diese in die Sprache mit aufnhemen muß, als attribute oder so,
es aber nicht tut, läuft man möglicherweise in die falsche Richtung.

Dein Tatendrang in allen Ehren, aber irgendwie kommt es auch schräg rüber...

So, und nun belassen wir es mal dabei.


Gruß,
   Oliver




Mehr Informationen über die Mailingliste linux-l