Wir wünschen als ausführendes Gerät jetzt ein Programm, das Jongleure (und Gegenstände) auf einem Bildschirm bewegt. Wir geben eine Beschreibung des zu werfenden Musters in einer geeigneten "höheren" Sprache ein, uns wollen uns eine Simulation des Musters ansehen. Warum?
Erstens möchte man oft einfach mal sehen, welchen optischen Eindruck (auf die Teilnehmer und das eventuelle Publikum) das Muster es denn machen würde, wenn man es denn könnte (und bevor man wirklich Zeit investiert, es zu üben).
Zweitens möchte man maschinelle Hilfe beim Entwerfen und Verifzieren von Mustern. Man kann ja nicht einfach alles irgendwann irgendwohin werfen, sondern es sollte schon jeder zu jedem Zeitpunkt genau eine Keule werfen und eine fangen. Dazu muß man das Muster gar nicht ausführen, die Verifikation entspricht lediglich einer Typ-Prüfung.
Damit verbunden ist die folgende Anwendung: man möchte (ein Lehrbuch) über Jongliermuster schreiben, und muß die Muster dazu sinnvoll (grafisch) auf Papier bringen.
Dritter Aspekt ist die (Bio-)Mechanik des Jonglierens. Man kann das eigene Jonglieren verbessern, wenn man sich seine Körper-Haltung und -Bewegung bewußt macht und mit Vorlagen (anerkannt gute Jongleure, oder eben sinnvolle Simulationen davon) vergleicht. Allgemeiner gesehen interessieren sich (Sport)(Bio)Mechaniker dafür, auf diese Weise etwas über den Bewegungsapparat des Menschen zu lernen. Herr Dr. Heiko Wagner (Jena) hatt beispielsweise Messungen von menschlichen Jonglierbewegungen (als 3D-Datensätze), an die man Knochen- und Muskelmodelle anpassen kann.
Zu Einzelheiten siehe diese Projektbeschreibung. Wer Interesse hat, daran mitzuarbeiten, gibt bitte Bescheid. Man kann das in verschiedenster Ausführlichkeit bearbeiten, und die genannten drei Schwerpunkte (High-Level-Beschreibung, physikalische Modellierung, Computergrafik) nach Wunsch betonen.
Was bei der Musik die Noten sind (Tonhöhe, Tondauer, Lautstärke), sind beim Jonglieren die Würfe. Wichtige Parameter sind: zu wer (mit welcher Hand) zu wem (und zu welcher Hand) wirft, und wann die Keule dort ankommen soll. Die nötigen Fänge können wir implizit lassen. Als Synchronisationszeitpunkte wähle wir jedoch genau das Fangen.
Ein Befehl "Jongleur 1, rechte Hand wirft zu Jongleur 3, linke Hand so, daß die Keule in genau einer Sekunde dort gefangen werden kann" können wir so umsetzen (wenn noch bekannt ist, daß man selbst die Keule jetzt im Moment fängt, und dann noch eine gewisse Zeit in der Hand bewegt): wir berechnen den Abwurfzeitpunkt und -Ort, auch die Flugdauer, damit die Flugbahn (in der Luft) und daraus den Anfangsimpuls (und Drehimpuls), den die Keule durch den Abwurf bekommen muß. Vom Fangen bis zum Wurf bestimmen wir die Kräfte, die die Arm-Muskeln aufbringen müssen, und simulieren dann alles.
Hier paßt noch ein weiteres, nichttriviales Projekt: wie berechnen wir denn diese Kräfte? Der Mensch rechnet ja auch nicht, sondern macht es einfach. Kann man das dabei nötige Üben und Probieren simulieren, also etwa so, wie man Roboter eine Bewegung lernen läßt? Es wäre sehr interessant, ein System zu simulieren (nur Schulter-, Ober- und Unterarmknochen und entsprechende Gelenke), das lernt, drei Bälle oder Keulen (schwieriger wegen des Drehimpulses) zu jonglieren. Wenn man entsprechende Hardware hat, kann man das ja auch wirklich mal aufbauen. Es gibt bereits "jonglierende Roboter" (drei Bälle), (TODO: link) aber die haben nichts eigentliches gelernt. Sie jonglieren "nur", weil die Fang- und Wurf-Mechanik sehr gut voreingestellt ist.
Zurück zur Eingabesprache: Für Solo-Balljonglage gibt es für eine bestimmte Klasse von Mustern eine sehr kompakte Notation (Site Swaps). Diese könnte man auch für Mehr-Personen-Muster benutzen, aber das sieht dann nicht sehr anschaulich aus. Es sind eben nur Folgen von Zahlen. Es setzt sich an dieser Stelle jedoch (bei einigen Autoren) eine grafische Variante der gleichen Idee durch: die Kausaldiagramme. Damit hat man eine schöne Partitur für das Jonglieren.
Nun gibt es seit einiger Zeit einen Kausal-Editor (TODO: link auf Wolfgang), aber ich stelle mir hier noch eine andere Variante vor, die helfen könnte, Muster zu variieren und zu erfinden: als Editieroperationen gibt es nicht das Einfügen und Löschen von Pfeilen, (beginnend mit einem leeren Blatt und abschließend mit einem gültigen Diagramm), sondern man beginnt mit einem bereits erzeugten (also vollständigem) Diagramm und hat dann als Editier-Operationen nur noch die, die nach der Siteswap-Theorie zulässig sind, also im wesentlichen diese: man markiert zwei Würfe A -> B und C -> D zum swappen: die Flugbahnen sind dann A -> D und B -> C.