MIDI von Anfang an: Standard-MIDI-Files intern
Atari und MIDI. Eine der erfolgreichsten Ehen der Computergeschichte. Und es sind auch die Musiker, die dem Atari die Treue halten. Und genau deshalb wollen wir dem Thema Atari & Musik auch in der st-computer in Zukunft wieder mehr Raum geben. Den Anfang macht geballte und im Lehramt erprobte Fachkompetenz. Professor Herbert Walz berichtet im fünften Teil seines MIDI-Tutorials von der Anwendung von Detailkenntnissen in der Praxis der Notation.
Um mit Standard-MIDI-Files besser arbeiten zu können ist es ganz hilfreich, wenigstens das Grundlegende dieses Musikformats zu verstehen. Auch wird man eher bereit sein auf Schwierigkeiten einzugehen, die sich beim Konvertieren hier und dort einstellen mögen. Als Notenbeispiel soll wiederum die - bereits im vorherigen Beitrag verwendete - einfache Kadenz dienen (Bild 1).
Dieses einfache Notenbeispiel wurde in ein Standard-MIDI-File gewandelt. Die Ansicht von dessen Innenleben wurde mit dem Disketten- und Festplattentool DISKUS von Dr. Uwe Seimet erstellt. Von demselben Autor stammt auch der Treiber für Festplatten und sonstige Laufwerke HDDRIVER, mit dem heute wohl die meisten Ataris und dazu kompatible Rechner arbeiten dürften.
In der Hexadezimal-Darstellung des Diskmonitors (Bild 1) stehen in der Spalte ganz links jeweils die Nummern des ersten Bytes in der Zeile. In der ersten Zeile ist das natürlich die 0. Im mittleren Teil der Darstellung stehen die einzelnen Bytes. Ein Byte hat bekanntlich 8 Bit. In Hexadezimal-Darstellung lässt sich mit einer Stelle der Zahlenbereich von 0 bis 15 darstellen. Für ein Byte benötigt man also zwei Stellen in hexadezimaler Darstellung. Diese Zweiergruppen sehen Sie im mittleren Teil der Darstellung. Ganz rechts erkennen Sie dieselben Daten in ASCII, was auch kaum mehr Klarheit schafft. Lediglich die ersten vier Zeichen „MThd" sind deutlich zu erkennen. Bei ihnen wird später die Erklärung der Bedeutung des vorliegenden Datenwirrwarrs beginnen. Zunächst sei noch darauf hingewiesen, dass man im Diskmonitor auch noch den Cursor setzen kann. Setzt man ihn im mittleren Teil, werden die zugehörigen Daten im rechten Bereich markiert und umgekehrt. So wird die Zuordnung der Daten wesentlich erleichtert.
Etwas gewöhnungsbedürftig ist die Handhabung des Wertes „00". Dieser wird als Leerstelle dargestellt, genauso wie die wirkliche Leerstelle „20". Aber dafür sieht die ASCII-Darstellung etwas übersichtlicher aus. In einem Debugger wäre „00" in der Hexadezimal-Darstellung auch als „0" in der ASCII-Darstellung zu sehen. Den Diskettenmonitor habe ich dem Debugger vor allem deshalb vorgezogen, weil sich von ihm problemlos Screen-Shots herstellen lassen. Der Pure-Debugger hingegen lässt keine Accessories zu. Diese werden aber gebraucht um die benötigten Bilder vom Bildschirm anfertigen zu können.
Das Standard-MIDI-File-Format
Nachdem also das Werkzeug vorhanden ist um das Innenleben von Standard-MIDI-Files zu ergründen, muss noch die Anordnung der Daten geklärt werden um diese mit vertretbarem Aufwand analysieren zu können. Dabei zeigt es sich, dass es drei verschiedene Typen von Standard-MIDI-Files gibt:
Format 0: 1 Track
Das einfachste Formal
Format 1: Viele Tracks.
Das wohl am meisten verbreitete Format
Format2: Enthält mehrere Standard-MIDI-Files vom Format 1.
Sehr komplex, bisher nicht benutzt
Das Format 0 soll als das einfachste der drei Formate zunächst analysiert werden. Dazu habe ich für mein Musikprogramm MusicEdit eine entsprechende Analysefunktion geschrieben (Bild 3). Diese wird aber nur in die Entwicklungsversion eingebunden. Für Musiker ist sie nicht von Interesse und würde das Programm nur unnötig aufblähen.
Das Standard-MIDI-File-Format ist ein sogenanntes „Chunk-Format", also ein Block-Format. Es besteht aus mehreren Blöcken, an deren Anfang ihre Bezeichnung und danach ihre Länge steht. Aus ihrer Bezeichnung ergibt sich ihre Bedeutung. Die Längenangabe dient der Kontrolle. Eine zusätzliche Erleichterung der Auswertung sind die mit doppelten Linien gekennzeichneten Zeilen. In ihnen wird die von der Analyseroutine ermittelte Länge ausgegeben, damit man diese nicht durch Nachzählen selbst ermitteln muß, was bei größeren Standard-MIDI-Files sehr zeitraubend wäre. Vorausgeschickt sei, dass in der Programmiersprache C/C++ „Ox" die Kennung für eine hexadezimale Zahl ist. Danach kommen die beiden Hexadezimal-Steilen die je vier - also insgesamt acht - Bit darstellen, was einem Byte entspricht.
Der Header-Block MThd
1. Zeile: Der erste Block beginnt mit der Zeile, in welcher „MThd" steht. Dies bedeutet „MIDI-Track-Header". Dieser Block wird meist nur kurz „Header-Block" genannt. Header bedeutet etwa Dateikopf. Links von MThd stehen vier Bit, die jeweils den ASCII-Code der vier Zeichen „MThd" im Hexadezimal-Format darstellen.
2.Zeile: In ihr steht die Anzahl der nachfolgenden Bytes in diesem Block. Das sind gerade einmal sechs an der Zahl, und zwar immer. Dazu würde das eine Byte ausreichen, das den Wert sechs tatsächlich enthält. Der Grund für die vier Stellen dürfte sein, dass Bezeichnung und Länge bei allen Blöcken gleich behandelt werden sollen. Schon der nächste Block kann nahezu beliebig lang sein. In diesem Fall werden die vier Stellen für die Längenbezeichnung auch wirklich benötigt.
3. Zeile: In ihr steht das Format. Dazu stehen zwei Byte zur Verfügung, obwohl auch hier ein einziges reichen würde. Im rechten von beiden steht ebenfalls eine Null, also handelt es sich um das Format 0.
4. Zeile: In ihr steht die Anzahl der nachfolgenden Tracks (was so viel wie „Spuren" bedeutet). Bei einem Standard-MIDI-File vom Format 0 steht dort immer eine 1, weil es ja nur einen Trackblock haben kann.
5. Zeile: In ihr stehen die Schläge pro Viertelnote, also die zeitliche Auflösung. In unserem Beispiel sind dies mit c = 12, also 12 *16 = 192.
Versucht man in der Darstellung des Diskmonitors die Inhalte der Zeilen 1 bis 5 aufzufinden, wird dies dadurch sehr erschwert, dass die Byte-Gruppen lückenlos aufeinander folgen. Sie sind nicht so hilfreich in einzelne Zeilen aufgegliedert, wie dies in der Analyse-Routine von MusicEdit der Fall ist. Gelingt die Darstellung, stößt man in der ASCII-Darstellung am rechten Rand auf die Buchstabengruppe MTrk. Diese ist zwar durch den Zeilenumbruch getrennt, was jedoch in den Originaldaten ohne Belang ist, weil es dort keine Lücken oder Zeilenumbrüche gibt.
Der Track-Block MTrk
1. Zeile: Der zweite Block beginnt mit der Zeile, in der „MTrk" steht. Dies bedeutet „MIDI-Track-Block", kurz „Track-Block" genannt. Links von MTrk stehen, wie beim vorherigen Block, die vier Bytes, welche die ASCII-Codes der vier Zeichen im hexadezimalen Format darstellen.
2. Zeile: In ihr steht die Anzahl der nachfolgenden Bytes in diesem Block. Von den vier Bytes, die diesen Wert repräsentieren, enthält jenes ganz rechts 0x58, also 516 + 81 =88. Hier erkennt man sehr deutlich, dass bei größerer Track-Länge die vier vorgesehenen Bytes durchaus benötigt werden.
3. Zeile: In ihr steht das erste Mal die sogenannte „Delta-Time", also der Zeitunterschied bis zum nächsten MIDI-Ereignis. Wenn die Delta-Time Null ist, bedeutet dies keinen Zeitunterschied, die Ereignisse passieren also gleichzeitig. Die Abfolge Delta-Time/Event muss immer eingehalten werden. Zur Anwendung kommt hier ein Format mit variabler Länge, damit man bei Zeiten, die in ein Byte passen, nur dieses eine Byte und bei längeren Zeiten so viele Bytes wie benötigt verwenden kann. Vor dem Wert der Delta-Time fügt die Analyse-Routine jeweils die Nummer des betreffenden Bytes hinzu, beginnend mit 0.
Die Nr. am Anfang der Delta-Time-Zeilen wird von der Analyseroutine hinzugefügt um lästiges Nachzählen zu ersparen. Es ist die Nummer des ersten Bytes in dieser Zeile. Diese bzw. die um eins höhere Nummer des ersten Bytes in der folgenden Zeile, soll bei den folgenden Zeilen verwendet werden.
4. Zelle oder 23. Byte: Dort steht das Kommando „PROGRAM CHANGE", das den Klang Nr. 74 auf MIDI-Kanal 1 einschaltet.
In den folgenden Zeilen werden auf den Kanälen 2 und 3 noch die Klänge 58 und 59 eingeschaltet.
32. Byte: In dieser Zeile steht zum erstenmal ein sogenannter „Meta-Event". Dies sind Ereignisse, die sich von den üblichen unterscheiden, weil sie nicht direkt musikalische Aktionen auslösen, sondern allgemeine Daten des betreffenden Musikstücks enthalten. In dieser Zeile ist es das Tempo, aus dem man die Metronomzahl 60 errechnen kann.
39. Byte: In dieser Zeile steht das Meta-Event „TIME SIGNATURE“. Daraus lässt sich der Takt (hier 4/4) und die Anzahl 1/32 pro Viertelnote, also 8 (was auch sonst?) ermitteln.
47. Byte: In dieser Zeile steht das Meta-Event „KEY SIGNATURE". Daraus lassen sich die Tonartvorzeichen (hier 2#) ermitteln.
53. Byte: In dieser Zeile steht das erste Kommando „NOTE ON". Damit wird auf Kanal 3 der Ton d mit der Dynamik mp eingeschaltet.
In den folgenden Zeilen werden die übrigen Töne des Anfangsakkords eingeschaltet.
64. Byte: In dieser Zeile steht die erste Delta-Time, die größer Null, nämlich 192, ist. Diese Zeit braucht zum erstenmal zwei Byte. Dies entspricht bei dem hier eingestellten Tempo einer Viertelnote. Da bis zu dieser Stelle im Standard-MIDI-File alle drei Töne des ersten Akkords eingeschaltet sind, wird dieser Akkord für eine Viertelnote ausgehalten.
66. Byte: In dieser Zeile steht zum erstenmal das Kommando „NOTE OFF". Der Ton al auf Kanal wird abgeschaltet um später durch einen anderen ersetzt zu werden.
So geht es nun weiter bis zum Ende des Standard-MIDI-Files. Dort steht das Meta-Event „END OF TRACK". Es besteht aus den drei Bytes FF 2F 00. Es ist aus Platzgründen in der Analyse-Darstellung nicht enthalten. Aber in der Darstellung des Diskmonitors kann man es am unteren Bildrand in der hexadezimalen Darstellung in der Bildmitte deutlich erkennen. Die drei nachfolgenden Bytes gehören nicht mehr zum Standard-MIDI-File. Die vorherigen Daten werden nur überschrieben. An den Stellen, an denen dies nicht geschehen ist, bleiben die alten Daten stehen. All dies erschwert die Analyse von Standard-MIDI-Files ungemein.
Standard-MIDI-Files laden und wiedergeben
Der zum Laden von Standard-MIDI-Files vorgesehene Menü-Eintrag befindet sich in der Regel im Menu Datei und heißt „Laden von Standard-MIDI-Files" oder auch „Import von Standard-MIDI-Files“. Bei MusicEdit erscheint nach dem Laden eines Standard-MIDI-Files der Dialog „Standard-MIDI-File wiedergeben“ (Bild 4).
Es gibt hier zwei unterschiedliche Verfahren. Bei manchen Musikprogrammen werden die Standard-MIDI-Files gleich während des Ladens in ein wiedergebbares Format gewandelt. Dies verursacht nur eine kaum merkliche Verlängerung der Ladenzeiten. MusicEdit verwendet ein anderes Verfahren, bei dem die Standard-MIDI-Files 1:1 geladen und dann während der Wiedergabe fortlaufend gewandelt werden. Dieses Verfahren ist besonders schnell, setzt aber eine entsprechende Rechenleistung und -geschwindigkeitsoptimierte Software voraus. Schon auf TT und Falcon ist dies möglich. Auf einem Milan geschieht dies mit derartigen Geschwindigkeitsreserven, dass der Vorgang auch im Hintergrund möglich wäre, wenn im Vordergrund z. B. ein Text geschrieben wird. Voraussetzung ist natürlich ein Multitasking-Betriebssystem wie N.AES oder das besonders schnelle MagiC. Ob diese Anwendung sonderlich sinnvoll ist, sei dahingestellt. Sie demonstriert aber vortrefflich die besondere Stärke des Atari und dazu kompatiblen Maschinen bei MIDI-Anwendungen.
Grafische Tools für die Notenwandlung
Mit dem Menu-Eintrag „MIDI-File umwandeln“ kann bei MusicEdit der Dialog „Standard-MIDI-File in Noten wandeln“ aufgerufen werden (Bild 5). Er enthält nahe dem oberen Rand den Titel des Standard-MIDI-Files und am linken Rand die Nummern der MIDl-Kanäle. Desweiteren werden in der linken Hälfte die aus dem Standard-MIDI-File gelesenen Analysedaten dargestellt: Klänge, Töne/Kanal, Format, Anzahl der Spuren, Metronomzahl, Tonart und Takt.
Die rechte Hälfte enthält Ergänzungsdaten, die zunächst als Vorschlagswerte aus den Analysedaten durch logische Verknüpfungen gewonnen wurden. Sie können jedoch auch durch Daten überschrieben werden, die aus eigenen Überlegungen hervorgehen. So ist es z. B. naheliegend, dass jeder Klang, also jedes Instrument, in einer eigenen Notenzeile notiert wird. Es werden aber auch manchmal zwei Instrumente pro Notenzeile notiert, eines mit dem Hals nach oben, das andere mit dem Hals nach unten. Bei dem hier zugrunde liegenden einfachen Beispiel ist jedes Instrument nur einstimmig. Die vorgeschlagene eine Stimme pro Notenzeile kann also beibehalten werden.
Der Vorschlagswert, den man ebenfalls nach eigenem Gutdünken abändern kann, beträgt vier Takte pro Notenzeile. Als minimale Tondauer wird 1/32 vorgeschlagen. Dies bedeutet, dass alle kürzeren Tondauern der sogenannten „Quantisierung" zum Opfer fallen. Bei der Umwandlung wird Tönen mit dem Vorzeichen „#" der Vorrang eingeräumt. Man kann jedoch durch Anklicken des b-Knopfes den b-Vorzeichen den Vorrang einräumen. Ein Notensystem muss jeweils zunächst neu erstellt werden. Da aber bei einem unbekannten Musikstück meist mehrere Versuche erforderlich sind, bis die Noten in einem passenden Notensystem angeordnet sind, ist es ratsam dieses, sobald es gefunden ist, als Vorlage zu sichern um es bei weiteren Versuchen mit dem Button „Laden" einfach wieder komplett laden zu können. Mit „Löschen" kann schließlich ein Standard-MIDI-File gezielt gelöscht und der dafür reservierte Speicher freigegeben werden.
Unschwer ist zu erkennen, dass die Umwandlung von Standard-MIDI-Files in Noten nicht zuletzt deshalb eine derart komplexe Aufgabe ist, weil nur Musik-und nicht Notendaten zur Verarbeitung vorgesehen sind. Aber dennoch haben moderne Musikprogramme diese Aufgabe in derart überzeugender Weise gelöst, dass gegenwärtig keine Anzeichen erkennbar sind die Weiterentwicklung in Richtung zu einem Musik-Datenformat, das auch Notengrafik einschließt, voranzutreiben.
Ausblick
Gerade das Standard-MIDI-File-Format kann dazu beitragen, dass Ataris und dazu kompatible Rechner Anschluss an die Welt der Standard-Computer halten. Aus diesem Grunde werde ich keine Mühen scheuen mein MusicEdit weiterzuentwickeln. Dabei fällt mir allerdings auf, dass es zunehmend schwerer wird, passende Beispiele bei anderen Musikprogrammen zu finden. Wenn ich dann für die in diesem Workshop benötigten Beispiele mein MusicEdit heranziehe, liegt dies weniger daran, dass ich hier die Internas am besten kenne, sondern zunehmend am Fehlen geeigneter anderer Musikprogramme.
Dieser Entwicklung muss entgegen gewirkt werden. Neue Hardware wird schließlich nur entwickelt, wenn es genügend Software dafür gibt. Mein Appell geht also an alle Leser hierbei mitzuhelfen. Kleinliche Kritik an der unbeabsichtigten Hervorhebung meines MusicEdit hilft nicht weiter, sondern nur tatkräftiges Entwickeln attraktiver Musik-Software - vor allem für die schon bestehenden und bereits angekündigten Atari-Kompatiblen. Ich würde diese neu geschaffene Vielfalt an MIDI-Software gerne in künftigen Beiträgen wiederspiegeln.
Herbert Walz