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

[Oliver Bandel]

On Thu, Sep 22, 2005 at 02:49:34PM +0200, Volker Grabsch wrote:
> Hallo Oliver!
> 
> Das ist wohl noch ein Missverständnis zu klären. Zuerst hatte ich
> geglaubt, du brauchst für Labanotation eine Scriptsprache.

Ja, eine eigene. :)


> 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; ob nun
in Python oder in OCaml.


> 
> Aber wie ich mitbekommen habe, willst du gar nicht in dieser Laban-
> Sprache programmieren.

Doch in gewisser Weise schon.
Man braucht aber eben nur ein kleines Subset von Funktionalität
einer allg. Sprache und dafür spezielle Features.
Deswegen ja auch die Erwähnung einer DSL.



> Wahrscheinlich brauchst du überhaupt keine
> 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.


> und falls doch, könnte das Einbetten von JavaScript
> etc. interessant sein,

hmhhh, ne.

> da gibt es sicher auch schon Engines, die dir
> das dann ausführen können.

Dann bin ich von der Güte der Engines abhängig.
Dann muß ich die Engines einbinden...
...dann kann ich auch gleich ein Subset selber entwickeln.

Nach JavaScript-Engines habe ich übrigens vor einer Weile mal geschaut,
denn ich war mit wget unzufrieden, weil der JavaScript nicht verdaute.
Hatte damals nix passendes gefunden.

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. :)
Und einen solchen wollte ich mir eh mal bauen, so daß ich Links
z.B. extrahiere, wenn der LinkText auf ein Pattern matcht oder so... :)

Hatte ich ja schon mal angefangen, aber nicht zuende gemacht.


> Aber wiegesagt, das brauchst du nicht,
> wenn ich dich richtig verstanden habe.

Kein komplettes Python oder so.
Ausser, man könnte die erlaubten Befehle limitieren.

Aber mir steht der Sinn da eher nach Selbstbau.
Dann habe ich da die Kontrolle, was das Teil kann und was nicht.


[...]
> Würde es nur um die Darstellung gehen, hätte ich dir sofort TeX oder
> Lout empfohlen,

sind beide zu nervig.

Hatte mir ketztens mal ein Teil gebaut,
da hatte ich als Ausgabesprache lout.
Hmhh, viell. wäre ich mit TeX wirklich besser gefahren,
aber es war jedenfalls mit lout und etwas zu strange
mit "was klammere ich und wie und was nicht".

Bei postscript hätte ich dann ggf. einfach gsave/grestore eingesetzt...
...da hat man mehr Kontrolle.
Aber dann müsste man leider den zeilenumbruch selbst zusammen
bauen; aber da gibt es ja schon Postscript-Code für.



> da hast du genau die Makro-Fähigkeiten, die du brauchst.

Die können viell. schon wieder zu viel, und desh.
zu wenig.

Deswegen mein Weg via Postscript.

Aber der Tip mit SVG war ganz gut.
Vielleicht ist das einfacher als Postscript zu nutzen.
Dann kommt ein Konverter dahinter (möglichst was fertiges)
und der macht daraus ps/pdf.


> Viel "Programmieren" hättest du in TeX nicht müssen, IMHO.

Ist eben immer so eine Sache. Hat man eine leistungsfähige
Ausgabesprache (*.ps, *.tex, ...) und macht dann die Ausgabe
nur in lowlevel-Kommandos, erledigt man alles im Programm,
vergibt man einige Möglichkeiten, u.a. auch die des nacheditierens
von Hand.
Gibt man eher Kommandos aus, die höheren Sprachleves sind, dann
hat man die Kontrolle vieler Dinge auch an diese Ausgabesprache zu übergeben.

Soll heissen: Man kann komplexe Grafiken in Postscript auch als
lines ausgaben, oder man kann komplexere Postscript-Operatoren
anwenden.
Baut man alles mit lines, muß man in der SW alles kontrollieren.
Dann also auch z.B. Umbruch.
Macht das die Ausgabesprache (Postscript oder TeX), ist es weniger
Programmieraufwand in der SW, aber es wird kniffliger, wenn man
in der möglicherweise schwierigeren Ausgabesprache alles umsetzen muß.

Bleibt wohl auch nur: ausprobieren.




> Aber du willst das nachher noch analysieren können, und das wird haarig.

Analyiseren z.B. von Skalensequenzen,
also
 scale H,D, DRF
und
 scale D,B, DLF

mit speziellen Funktionen vergleichen (auf Eigenschaften).
Oder generieren neuer Sequenzen aus diesen Ausgangssequenzen...




> 
> Deshalb brauchst du auf jeden Fall ein extra Format, das jeder parsen
> kann und das lange Zeit möglichst einfach und stabil bleibt. Hier nimmt
> dir XML sehr, sehr viel ab, deshalb habe ich "LabanXML" empfohlen.

Das soll aber high-level / semantisch sein, nicht nur die Grafikobjekte beschreiben.
Sonst ist es kein Fortschritt gegenüber derzeitigen Ansätzen (LabanWriter).


> 
> Hieraus kannst du dann z.B. LaTeX-Code erzeugen, es braucht nur
> einfacher Code zu sein, denn alles, was ständig mit generiert werden
> müsste,

Naja, gäbe es eine Laban-XML, so wäre auch das Analysieren viel einfacher.

Vielleicht sollte ich erst mal mit MusicXML herum probieren und schauen,
was man damit so alles machen kann.
Als Vorstufe für Laban-XML.


[...]
> Rotation und Spieleung von
> Symbolen, vertikale Anordnung, .... das ist alles noch Textsatz.

Naja, wenn man stat Font dochGrafiksymbole nimmt, wäre es Grafiksatz.
Bin mir noch unschlüssig...

Für die einbfachen Skalen mit nur Richtungsangaben scheint aber der
Ansatz mit Textsatz ideal zu sein.

Für die ausführliche Laban-Notation muß man dann doch auf Grafikbasis
weiter machen (wegen der genauen Positionierung).

[...]
> Schau dir SVG an, und dann kannst du immer noch entscheiden, wie du

Das scheint mir ein geeignetes Format zu sein, wenn ich Deine
Ausführungen dazu betrachte.


> den Weg LabanXML -> SVG oder LaTeX machen willst.

Wenn es eine Laban-XML gäbe, wäre auch OpenGL/3D-Animation
von Interesse. :)

Hatte damals schon mal ein bischen was dafür vorbereitet,
war aber erst mal nur ein Gerüst, und alles in ANSI-C,
aber multithreadedd und OpenGL lief auch (aber nur eine
Beispiel-Applikation als "Platzhalter" für den echten Laban-Krams).

Würde ich vermutlich heutzutage alles in OCaml machen.
OpenGL-Bindings gibt es ja.


[...]
> Eine editorfreundliche Sprache, die für Anfänger geeignet sein soll,
> hat mir der ganzen Sache bisher nichts zu tun.

Doch.
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. oder es kommt dan doch eine GUI dazu - wäre aber dann alles
in OpenGL.


> Wenn dieses Textformat
> unbedingt selbstgestrickt sein soll, sollte es eine Teilmenge von einer
> Textsatz-Sprache oder einer Wiki-Sprache sein ... idealerweise eine
> Teilmenge von TeX. Aber S-Expressions oder ähnliche Sprachen sollten
> schon komplett ausreichen, sind übersichtlich und erfüllen deinen Zweck
> voll und ganz.

TeX reimplementieren?
Nein danke!


[...]
> Du siehst, ich schlage eine starke Aufgabenteilung vor, um zu
> verhindern, dass du zu viele Probleme in Verbindung bringst, die gar
> nichts miteinander zu tun haben.

Keine Sorge.
Das Konzept steht schon seit ein paar Jahren, zumindest im groben.


[...]
> Nur eine interessante Querverbindung wäre noch denkbar und vielleicht
> cool: Wenn die editorfreundliche Sprache nicht eine Teilmenge von
> TeX wäre,

Nu' iß aber gut!
Ich baue doch nicht TeX nach!?!

Ciao,
   Oliver