2.2 Die Codierung der Noten 59 durch Zahlen, sondern durch die Anfangsbuchstaben der englischen Bruchzahlwör-ter codiert. Ein Multiplikator hinter einem dieser Buchstaben, z.B. x4, bewirkt eine entsprechende, Tipparbeit verringernde Parameterrepetition. Nach der leeren drit-ten Zeile – sie könnte Artikulationsangaben enthalten – folgen die Informationen zur Balkensetzung. Dabei muß sich der Autor die Noten von 1 bis 13 durchnume-riert vorstellen und anhand dieser Zahlen jeweils Balkenanfang und -ende in Form von Zahlenpaaren definieren. Analog dazu wäre das Hinzufügen von Bögen mittels des fünften Eingabeabschnitts möglich. Obwohl sich die sukzessive Parametereingabe beim Transkribieren von Partitur-vorlagen durchaus als vorteilhaft herausstellt, bedarf das nachträgliche Editieren einiger Eingewöhnungszeit. Ein falsch eingegebener Notenwert stellt sich in aller Re-gel erst nach Generierung des Notenbildes als fehlerhaft heraus, so daß die äquiva-lente Stelle im Code aufgesucht und korrigiert werden muß. Genau dies wird durch die Trennung der Parameter erschwert, denn auf welche Noten sich ein qx2 bezieht, kann im ungünstigsten Fall nur durch umständliches Abzählen der Elemente in der Tonhöhenzeile ermittelt werden. Nachträglich hinzugefügte oder entfernte Noten bzw. Pausen wirken sich noch verheerender aus, da sich sämtliche Parameter der zweiten bis fünften Eingabezeile entsprechend verschieben und ebenfalls nachzube-arbeiten sind. Aus Sicht des Anwenders ist der Code also sehr gewöhnungsbedürftig und sicher nicht als intuitive, leicht zu beherrschende Eingabeschnittstelle geeignet. Dem Computer hingegen ist es letztendlich egal, in welcher Reihenfolge die Para-meter übergeben werden, doch nichtsdestoweniger lassen sich Codemanipulationen an zusammenhängenden Textbausteinen einfacher realisieren, als an getrennt zu bearbeitenden, aber sich aufeinander beziehenden Parameterlisten. Insgesamt hat sich nach der Untersuchung verschiedenster Eingabesprachen ge-zeigt, daß von den existierenden Codes nur wenige für einen sinnvollen Einsatz als Kommunikationsschnittstelle zwischen Programmautor und Computer geeignet sind. Dies ist auch nicht besonders verwunderlich, denn kein Code wurde speziell für den Einsatz in Lernumgebungen entwickelt, die vielfältige Code-Manipulationen während der Laufzeit erfordern. Entweder liegt ihre Aufgabe in der detaillierten textuellen Abbildung einer Partitur mit entsprechend umfangreichen und teilweise graphisch orientierten Parameterangaben oder in einer schnellen Erfassung ein-stimmiger Themen und Motive, welche wiederum keine polyphonen Notenbeispiele berücksichtigt. Trotzdem erweist sich gerade der monophon angelegte Plaine and Easy Code als ideale Grundlage. Seine formatfreie Konzeption und die intuitive Notenbeschreibung haben sich bereits in den Gehörbildungsprogrammen des Com-puterkollegs Musik bewährt – sowohl auf Seiten der Programmierung im Bezug auf eine einfache Integration via Strings oder externer Dateien, als auch auf Seiten der Codierung von Notenbeispielen durch weniger programmiererfahrene Autoren. Darauf aufbauend sind nun verschiedene Erweiterungen zur zusätzlichen Erfas-sung polyphoner Strukturen denkbar, die an dieser Stelle jedoch nicht genauer spezifiziert werden sollen. In Abhängigkeit vom jeweiligen Einsatzgebiet kann es durchaus sinnvoll sein, die Code-Syntax von Fall zu Fall abzuändern. Wichtiger als der Entwurf eines weiteren Code-Dialekts scheint deshalb die Austauschbarkeit der Eingabesprache durch einen entsprechend modularisierten Parser.