Vorlesung: Praxis der Funktionalen Programmierung | Index

Wünschenswerte Erweiterungen des Sequencers

Zunächst ist wünschenswert, daß das alles geht, was ich bisher aufgezählt habe. Da ist aber nichts fundamental schwieriges dabei, das Interpretieren von Sprachen (Let-Bindungen für Funktionen) haben wir schon gesehen, und das Parser-Bauen auch. Zur GUI-Programmierung und Echtzeit haben wir heute einiges gehört. Da braucht man "nur" mal ein freies Wochenende und kann die Sache wesentlich voranbringen.

Dann ist noch lange nicht Schluß - man könnte nachdenken über weitere Eingabe-Elemente. Nahe liegt der Wunsch nach dem Einlesen von Midi-Strömen, und dem Reagieren darauf. Wo kommen die her? Vielleicht von anderen Sequenzern, oder jemand spielt live eine Melodie ein, die wir dann bearbeiten, oder, und das sollte am besten jetzt schon gehen, die Daten kommen von den Drehknöpfen eines Phatboy. Warum wünschen wir uns das als Eingabegerät? Knöpfchendrehen ist irgendwie viel unmittelbarer als Mausbetätigen. Außerdem kann man gleichzeitig zwei Knöpfe drehen, aber nur eine Maus. - Im Prinzip können wir leicht /dev/midi lesen, aber wir haben wie oben wieder das Problem der Pufferung.

Da wir nie genau wissen, wie lang denn gerade die Leitung ist, können wir den Eingabestrom, der zum Beispiel eine Melodie enthält, nicht "sobald als möglich" spielen - der Einsatzzeitpunkt wäre dann unbestimmt. Wir müssen irgendwie synchronisieren, d. h. ein Raster für mögliche Einsatzpunkte festlegen.

So etwas ist sowieso sinnvoll: bis jetzt dachten wir, der Interpreter führt einfach ein Programm aus, d. h. er beginnt bei main und macht dann eben das, was dasteht. Tatsächlich kann man ja nicht alles vorhersehen, und möchte sich dann live entscheiden, hier und dort zu clicken und damit Unterprogramme zu starten. Das erfordert eine weitere Bedienlogik: bisher waren die Eingabelemente Schieberegler (für Zahlen) oder Knöpfe (für Booleans). Dann brauchen wir Feuerknöpfe, hinter denen eine Aktion (d. h. also wieder ein IOStream) wartet - und die Knöpfe selbst werden von einem eingehenden IOStream aktiviert.

Vielleicht wollen wir die Tatsache der Aktivierung dem Nutzer mitteilen. Überhaupt könnten wir verschiedenes mitteilen. Ausgabemöglichkeiten gibt es aber beim jetzigen Entwurf nicht (außer der Midi-Ausgabe natürlich). Wir können einfach im Ausgabestrom auch print-statements gestatten, die dann eben nicht an das Klavier gehen, sondern an den Bildschirm. Aber dort wohin?

Als billigste Variante in ein Statuszeile, aber schöner wäre es doch, wenn wir erstens nicht nur Text ausgeben, und zweitens an selbst gewählten Stellen. Am besten gleich dort, wo der Programmtext steht! Allerdings können wir keine Anweisungen zur Ausgabe schreiben. In unserer Sprache gibt es zum Glück keine Anweisungen (sondern höchstens Ausgabeströme).

Wenn wir nun irgendwo im Programmtext deklarien könnten "Zeige an dieser Stelle einen Schieberegler, dessen Stellung jeweils gleich dem Wert des Ausdrucks x ist", dann müssen wir sehr genau nachdenken, welchen Wert wir meinen. Es könnte verschiedene Aufrufketten geben, die die Funktion enthalten, in der das Ausgabe-Element deklariert ist, und jede hat vielleicht einen anderen Wert für x. Dann ist guter Rat teuer. Am besten, man wartet, bis jemand eine echte Anwendung hat, d. h. eine Idee für einen Musik-Algorithmus, bei dem er eine solche Ausgabe braucht. Dann wird man sehen, welche Lösung paßt.


best viewed with any browser


http://www.informatik.uni-leipzig.de/~joe/ mailto:joe@informatik.uni-leipzig.de