Grundlagen: Was leistet das MIDI-Tasking-System M-ROS
Bei dem Wort Multitasking denken viele Anwender sicherlich an MultiTOS, Windows, oder gar OS/2, alles Betriebssysteme, die es gestatten, mehrere Programme gleichzeitig aktiv im Speicher zu halten. Das MIDI-Tasking-System M-ROS hat dagegen eine etwas andere Aufgabe: Es organisiert die Ein-und Ausgabe von MIDI-Daten und die Synchronisation mit der Außenwelt. Die Anzahl der Programme, die dabei auf M-ROS zugreifen, spielt dabei keine Rolle.
M-ROS (MIDI Realtime Operating System) war ursprünglich als Sammlung von Tools zur Entwicklung des Twenty-Four Sequenzer-Program ms geplant. Es galt damals, das SMP24 anzukoppeln und eine allgemeinere Form zu finden, MIDI-Daten zu verwalten und Timecode Synchronisation zu ermöglichen. Bald stellte sich jedoch heraus, daß diese Tools einen immer universelleren Charakter bekamen, so daß die Idee aufkam, eine für alle MIDI-und Echtzeitprogramme gemeinsame Plattform zu schaffen. Zunächst einmal ist M-ROS vollständig Hardware-unabhängig. Die einzige Voraussetzung für das Funktionieren von M-ROS ist ein Timer(-Interrupt). Daher ließ sich M-ROS problemlos vom Atari ST auf Apple Macintosh und schließlich IBM-PC (und kompatible) Rechner portieren. Die beinahe vollständige Implementierung in ANSI-C ab der Version 3.0 erleichterte die Portierungsarbeiten zusätzlich. M-ROS selbst gliedert sich im wesentlichen in folgende drei Teile: Den Message Manager (MEM), den Input Output Manager (IOM) und den Time Manager (TM).
Wie bereits eingangs bemerkt, ist M-ROS in erster Linie für die Verwaltung von MIDI-Daten zuständig. Wie wir sehen werden, erledigt M-ROS aber auch noch weit darüber hinausgehende Aufgaben. So verwaltet es z.B. zusätzliche Peripherie, wie das MIDEX, den C-LAB Export, das Steinberg SMP 124, Interfaces zur Steuerung von Bandmaschinen und vieles mehr.
Die Kommunikation mit diesen »Devices« erfolgt über sogenannte »Device Driver«, auf deutsch: Gerätetreiber. Ein Device Driver nimmt M-ROS den Großteil der Arbeit bei der Verwaltung der Peripheriegeräten ab. M-ROS lädt diese Treiber beim Start und führt sie aus. Der Treiber wiederum meldet sich nach seiner Grundinitialisierung bei M-ROS an. Er übergibt eine vollständige Beschreibung seiner selbst, auf die später auch die Applikationen Zugriff haben.Einmal geladen, bleiben sowohl M-ROS als auch seine Device-Driver im Speicher resident, ohne irgendwelche Aktivitäten zu entwickeln. Erst wenn der erste Open_mros Aufruf stattfindet, aktiviert M-ROS seine »Manager« und die Devices. Der Device-Driver versucht nun, seine Hardware zu finden, und setzt sich selbst je nach Erfolg aktiv oder inaktiv. Ab jetzt stehen den Applikationen alle Fähigkeiten des M-ROS und seiner Devices zur Verfügung.
Ein M-ROS-Device kann MIDI-In-und Outputs besitzen, Timecode oder Tempo Sync Clocks liefern, Timecode generieren, eigene Funktionen anbieten usw. Für MIDI-Ports gibt es spezielle Strukturen, in denen die Inputs/Outputs genau beschrieben sind. Daneben gibt es die < Autolocator >, die die Steuerung von Bandgeräten übernehmen etc.
Der Message Manager
Der MEM hat nicht besonders viel zu tun, vergleicht man seinen Funktionsumfang mit dem des IOM und des TM. Dennoch erfüllt er wichtige Aufgaben.
Zunächst einmal meldet sich jede M-ROS Applikation über »Open__mros« an, bzw. über »Close____mros« wieder ab. Dabei übergibt die Applikation eine Struktur, die im wesentlichen eine Message-Empfangsfunktion beinhaltet und erhält dann vom MEM ein »handle« zurück (vergleichbar mit open___workstation im AES). Immer, wenn nun etwas Einschneidendes in der M-ROS-Welt passiert, schickt der MEM eine entsprechende Message an alle Empfänger. Dies sind im Wesentlichen sogenannte Transport-Funktionen wie Start, Stop, Cycle Change, Tempo Change, Sync Change usw. Außerdem findet der MEM bei Bedarf andere Applikationen nach Name oder Nummer. Alle M-ROS-Anwendungen kommunizieren untereinander über den MEM. So teilt ein Sequenzer z.B. den sogenannten »Autolocator Devices« (Bandmaschinen Controller) mit, welche Tracks aufzunehmen oder wiederzugegeben sind. Es gibt noch etliche Funktionen und Details des MEM. So lassen sich z.B. besonders wichtige Zeiger auf Daten und Funktionen des M-ROS erfragen. Durch Umbiegen eines solchen Zeigers kann ein Device z.B. die Transport-Funktionen übernehmen (Auto Locator) oder den TM mit Clocks versorgen (Digital Audio Synchronisation). Bei M-ROS handelt es sich also um ein offenes System, das auch Fremdeingriffe erlaubt.
Der IOM behandelt auf unterer Ebene alle MIDI-Daten. Er nimmt sie von einem Device mit MIDI-Eingängen in Empfang und sendet MIDI-Daten zu Devices mit MIDI-Ausgängen. Applikationen erhalten durch spezielle Funktionen Zugriff auf den IOM. So lassen sich z.B. MIDI-Daten in Form von Bytes, MIDI Channel-Events oder gar Dumps beliebiger Größe versenden. Dem IOM muß man zu diesem Zweck lediglich das entsprechende Device, den Output und die Daten (oder einen Zeiger darauf) übergeben. Die Applikation kann bestimmte Ausgabe-Funktionen für schnelle Ausgaben direkt anspringen.
Um Probleme beim Transfer großer Datenmengen (System Exclusive oder Blöcke beliebigen Inhalts) zu umgehen, installiert der IOM eine verkettete Liste von Tasks mit jeweils eigenen Daten und Pointern. Darüber hinaus lassen sich solche Tasks auch direkt anmelden.
Beim Empfang von Daten gibt es zwei Möglichkeiten. Für einfachere Programme reicht es aus, den IOM zu fragen, ob Daten im Buffer vorliegen und diese gegebenenfalls abzuholen (so wie Bconstat und Bconin im Atari). Da aber nur eine Applikation zur Zeit den Buffer leeren kann, ist diese Methode im Multitasking nicht ausreichend. Daher melden derartige Applikationen über »Open___io« einen Task an, der empfangene MIDI-Daten direkt mitgeteilt bekommt.
Open___io übergibt ähnlich wie Open___mros eine Struktur und liefert ein handle zurück. Diese Struktur enthält neben dem Empfänger auch Informationen über die für die Applikation gültigen Inputs. Der IOM übergibt wiederum der Receive-Funktion den Input. Der zu Beginn beschriebene Device Manager bildet übrigens eine Unterabteilung des IOM.
Der Time Manager
Der TM hat nicht nur die umfangreichste Bibliothek von Funktionen, sondern stellt den wohl mächtigsten Teil des M-ROS da. Dadurch unterscheidet sich M-ROS auch von anderen, anscheinend vergleichbaren Systemen. Neben den Lösungen, die der IOM und seine Devices zur quasi gleichzeitigen Verwaltung aller MIDI-Daten bieten, erfordert ein echtes Realtime-Multitasking das synchronisierte und zeitgenaue Processing aller Events. Insofern sind an den TM viel höhere Anforderungen zu stellen als an ein normales Multitasking, bei dem die zeitliche Präzision im Gegensatz zur möglichst hohen Arbeitsgeschwindigkeit keine allzu ausschlaggebende Rolle spielt.
Der TM verbindet nun die Forderung nach exaktem Timing und schneller Performance, wobei er zusätzlich auch noch die Rechenzeit nach Dringlichkeit geordnet verteilt. Die hierfür notwendige Zeitbasis erhält der TM in Form eines Timer-Interrupts. Beim M-ROS ist diese »timer rate« von den Timecode-Frames abhängig (24, 25, 30 bzw. 30 drop frame), d.h. 24,25 oder 30 Bilder/Sekunde. Diese Frames unterteilen sich wiederum in 80 Subframes, die die Zeit- und Rechenbasis für den TM bilden.
Bei den in Europa üblichen 25 Bildern pro Sekunde dauert ein Subframe dementsprechend 500 Mikrosekunden (1 Sekunde/25/ 80). Der Timer-IRQ des TM läuft im allgemeinen auf der Basis von zwei Subframes, also ca. einer Millisekunde.
Und was hat das alles mit Musik zu tun? Das musikalische Geschehen ist ja nicht, wie der Timecode, an eine feste Zeitbasis gebunden, sondern folgt einem variablen Tempo. Deshalb läuft der TM immer auf zwei verschiedenen Zeitscheiben: Den bereits erwähnten Subframes und den »PPQ-Ticks« (Pulse per Quarter Note), die dem Tempo folgen.
Die Zahl dieser Impulse ist beim M-ROS auf 384 Ticks pro Viertelnote festgelegt. Manchmal rechnet man auch in Pulses per Bar, also taktbezogen (entspricht 384 x4 = 1536). Die Experten streiten sich darüber, ob höhere Auflösungen sinnvoll sind. Beim M-ROS haben wir uns hauptsächlich aus zwei Gründen dafür entschieden, diese Auflösung beizubehalten:
Zum einem gibt es eine Schwelle, unterhalb derer das Gehirn akustische Ereignisse zu Mustern zusammenfaßt (also nicht mehr unterscheiden kann). Diese Schwelle liegt nun genau im Bereich von 1 bis 2ms. Zum anderen verbraucht eine höhere Auflösung auch deutlich mehr Rechenzeit. Das Umrechnen von Subframes auf PPQ erfolgt leider nicht linear. Daher muß M-ROS z.B. beim Positionieren des Systems umfangreiche genaue Berechnungen mit großen Zahlen anstellen, um stets beide Zeitebenen gleichauf zu halten. Nebenbei stellt der TM die Zeit übrigens auch immer unabhängig von den Frames in Millisekunden zur Verfügung.
Um nun einen Task beim TM über »open—tm« anzumelden, übergibt die Applikation eine Struktur, in der sich der Task selbst beschreibt. Wesentlich ist hier, wie oft und wann der TM diesen Task aufrufen soll, und auf welcher Zeitscheibe der Task laufen will (Timecode oder PPQ). Darüber hinaus lassen sich Funktionen anmelden, die der TM bei Start/Continue, Stop, Posit, Cycle Freeze und Cycle Restore und im Stop Modus aufruft. Dazu später mehr. Zuvor jedoch einige Worte über einen ganz wichtigen Aspekt des TM, die Priorität.
Das Prioritäts-System des Time-Managers erlaubt es, verschieden wichtigen Aufgaben unterschiedliche Prioritäten zuzuordnen, so daß sich also mehrere Tasks mit verschiedener Dringlichkeit installieren lassen. Dabei ist zwar ausgeschlossen, daß sich ein Task selbst überholt, ein höher priorisierter Task kann aber jederzeit Tasks auf den unteren Ebenen unterbrechen. Dieses System ist maßgeblich für die Qualität des Timings verantwortlich.
Exakte Synchronisation
Das Cycle-System erlaubt einen schnellen Rücksprung auf den »Left Locator«. Dazu fordert der TM alle beteiligten Tasks auf, die wesentlichen Daten für den Cycle-Anfang (also den Left Locator) bereitzuhalten. Er ruft dazu alle Cycle Freeze Funktionen auf. Erreicht die laufende Position das Ende des Cycles (Right Locator), fordert der TM die Cycle Restore Funktionen auf, den Zustand des Cycle Starts möglichst schnell wiederherzustellen. Dabei geht häufig, wie übrigens auch in anderen Situationen, Zeit verloren, die der TM aber erkennt und wieder aufholt. Zusätzlich kümmert sich der TM auch noch um die gesamte externe Synchronisation. Diese läuft unabhängig voneinander auf den beiden erwähnten Zeitscheiben (Timecode und PPQ) ab. Den hierzu notwendigen Synchronisationspuls liefern entweder die Devices oder aber die MIDI-Peripherie in Form von MTC bzw. MIDI Clock. Außerdem beherrscht M-ROS noch die Synchronisation via »Human Sync«, eine spezielle, vom Einspieltempo abhängige Tempo-Steuerung. Um ein Höchstmaß an Sicherheit zu gewährleisten, erkennt der TM bei der Verarbeitung von Timecode selbständig Dro-pouts. Variablen des TMs stehen dem Programmierer zur Verfügung, um Einlock- bzw. Dropout-Zeiten einzustellen, Frame Chan-ges, stehenden oder geschnittenen Timecode zu erkennen.
Weiterhin bietet der Time-Manager umfangreiche Funktionen, Zeiten in beliebigen Formaten anzubieten, und das aktuelle Tempo, die Time-Signature sowie die Timecode- und PPQ-Zeiten rasch zur Verfügung zu stellen. Selbstverständlich lassen sich die verschiedenen Zeitformate konvertieren. Der TM enthält noch eine ganze Reihe weiterer Funktionen (z.B. zur Steuerung vom Count-In, Verwaltung des Mastertracks etc.), deren Beschreibung allerdings den Rahmen dieses Artikels deutlich sprengen würde. Trotz seiner Funktionsvielfalt bleibt der TM aber stets für Programmierer überschaubar.
Nach dieser Einführung in den prinzipiellen Aufbau von M-ROS könnte nun der Eindruck entstehen, es handle sich hierbei um ein hochkompliziertes, nur schwer zu handhabendes System. Doch das Gegenteil ist der Fall. M-ROS verfügt über eine Handvoll einfach zu nutzender Basisfunktionen, mit denen sich einfachere MIDI-Applikationen schnell realisieren lassen. Mit steigender Erfahrung und/oder wachsendem Anspruch an die Komplexität der Anwendung zeigt sich M-ROS jedoch auch offen für sehr detaillierte Eingriffe von außen und kompliziertere interne Manipulationen. Die uneingeschränkte Praxistauglichkeit des M-ROS-Konzepts beweisen nicht nur die Produkte der Firma Steinberg selbst, sondern auch die Entwicklungen anderer Anbieter, die M-ROS in Lizenz zur Programmierung eigener Sequenzer, Mischpult- und Lichtautomationen sowie zur Digital-Audio Steuerung verwenden. (wk)
Karl Steinberg