2.1 Anforderungen an ein bildschirmorientiertes Notenmodul 41 Die semantische Zusammensetzung der Eingabeinformationen ist damit festge-legt, offen bleibt hingegen die Frage nach der Art der Noteneingabe. Hierfür gibt es im wesentlichen zwei Ansatzpunkte. Zum einen besteht die Möglichkeit, dem Ge-nerator wie den ersten Batch-Systemen1 eine Skriptsprache zugrunde zu legen, die sowohl vom Nutzer als auch vom Computer gelesen und verstanden wird. Die No-teninformationen werden dabei mit mehr oder weniger intuitiven Kombinationen aus Buchstaben, Ziffern und anderen Symbolen der Computertastatur beschrieben und wahlweise in einer separaten Datei abgelegt oder in Form einer Datenstruktur direkt in das Anwendungsprogrammeingebettet. Der Notengenerator liest dann bei seiner Aktivierung diese Zeichenfolge ein, analysiert die syntaktischen Bestandteile, ordnet ihnen eine bestimmte Bedeutung zu und richtet daraufhin seine interne No-tenbildrepräsentation ein.2 Die zweite Möglichkeit der Eingabe zeichnet sich für den Nutzer durch einen höheren Komfort bei der Eingabe und für den Computer durch ein günstigeres Eingabeformat aus. Anstatt wie bei den alphanumerischen Codes einen gemeinsamen Nenner bezüglich der Eingabeschnittstelle zu finden, bedient sich der Nutzer hierbei zusätzlicher Werkzeuge. So kann er beispielsweise graphi-sche Hilfsmittel einsetzen, welche die Noteneingabe durch einen geeigneten Editor erleichtern. Die vom Notenmodul benötigten Eingabedaten werden im Anschluß an die Eingabe automatisch erzeugt. Da der Anwender des Notenmoduls hierbei nicht unmittelbar mit dem Eingabeformat in Kontakt kommt, kann dies computer-gerechter und gleichzeitig für den Menschen unleserlicher ausfallen. Zwangsläufig wird dem Programmierer einer Lernanwendung damit die Möglichkeit genommen, auf einfache Weise Notenbeispiele zur Laufzeit zu erzeugen bzw. vorhandene zu manipulieren. Das Notenmodul müßte in diesem Fall zusätzliche Funktionen zum Umgang mit dem Eingabeformat bereitstellen, die quasi als Übersetzer zwischen Programmautor und Notenmodul dienten. Dieser Weg dürfte sich allerdings schnell als nicht sonderlich effektiv herausstellen, da lediglich auf die zur Verfügung gestell-ten Funktionen zurückgegriffen werden kann. Neue, noch nicht implementierte, auf den Eingabeinformationen operierende Transformationen lassen sich hierbei vom Modulnutzer aufgrund der Code-Abkapselung nur schwer realisieren. Aus den ge-nannten Gründen scheint die Eingabe über einen gemeinsamen Eingabecode für den hier zu berücksichtigenden Anwendungsbereich besser geeignet. Dieses Vorge-hen erlaubt einen unmittelbaren Zugriff auf die Eingabedaten und damit im über-tragenden Sinn eine direktere Kommunikation mit dem Modul. Die Frage nach Beschaffenheit und Aufbau eines geeigneten Eingabecodes soll im nächsten Ab-schnitt 2.2 beantwortet werden. Nachdem das Notenmodul die Informationen der Eingabedatei eingelesen und semantisch interpretiert hat, muß es daraus die schon mehrfach erwähnten latenten Parameter ermitteln. Dazu gehören in erster Linie die zur Lesbarkeit der produzier-ten Noten unverzichtbaren Kollisionsvermeidungen. Jedes Notationselement besitzt relativ zu den anderen eine recht eindeutig definierte Standardposition, die durch die notenschriftliche Orthographie definiert wird. Beispielsweise werden Noten mit derselben Einsatzzeit normalerweise direkt untereinander notiert und die eventuell vorhandenen zugehörigen Versetzungszeichen befinden sich in unmittelbarer Nähe 1 Vgl. auch Abschnitt 1.3 dieser Arbeit. 2 Detailliertere Ausführungen dazu finden sich im Abschnitt 3.1 dieser Arbeit.