Europäische Anforderungen an das AES-24 Protokoll
Vortrag zur Tonmeistertagung 1996
Anforderungen
Lassen Sie uns nun zu den Anforderungen kommen, die seitens verschiedener europäischer Hersteller an die SC-10-2 Arbeitsgruppe des AES-24 Ausschusses herangetragen werden.
Wie schon Eingangs erwähnt, muß man nicht unbedingt von einer speziellen Anforderung sprechen, obwohl bei der Durchsicht des Protokolls und der gebotenen Möglichkeiten sich besonders eine wünschenswerte Eigenschaft förmlich aufdrängt: Die automatische Erkennung von Geräten durch einen „generischen“, also offenen und allgemeinen Controller. Dieser erkennt die im Gerät enthaltenen Steuerobjekte und stellt entsprechende graphische Elemente auf dem Bildschirm zur Verfügung. Hiermit wird erreicht, daß auch Geräte, deren Steuersoftware nicht zur Verfügung steht, geregelt und überwacht werden können. Diese generische Steuersoftware ist zwar nicht so schön wie vom Originalhersteller, erfüllt aber ihren Zweck.
Einfacher gesagt als getan! Wie könnte diese nützliche Eigenschaft nun verwirklicht werden? Das Fragezeichen ist bitte wörtlich zu nehmen, da man sich im SC-10-2 Ausschuß noch nicht im Klaren über die Realisation ist. Anregungen in diese Richtung sind daher willkommen.
AES-24 ergreift verschiedene Maßnahmen, um über ein Netzwerk sinnvolle Auskunft zu erhalten bzw. den System Controllern solche geben zu können. Hierbei ist es notwendig, mit Hilfe eines sog. System Builders alle notwendigen Steuerpfade zu errichten. Hierzu sind natürlich ebenfalls verschiedene Schritte vorzunehmen.
Der System Builder (=System Architekt) bekommt vom Register Auskunft, wieviele verschiedene Handles im System enthalten sind und muß daraus die Steuerpfade erstellen. Es ist außerdem notwendig, daß der System Builder hierzu die zum Netz gehörigen Objekte anspricht und Informationen über sie bzw. die richtigen Verbindungen ablegt (registriert). Zusätzlich unterrichtet das Register den System Builder über die entsprechenden Steuerbereiche der enthaltenen Handles.
Über die Informationen hinaus, die ein System Builder vom Register erhält, kann er über einen Vorgang, den AES-24 als „Discovery“ definiert, genaue und detaillierte Auskünfte von den beteiligten Geräten erhalten. Es ist durchaus möglich, daß der Discoveryprozess Informationen liefert, die nicht im Register abgelegt sind, da sie evtl. im Konflikt mit bestimmten Handles anderer Geräte stehen oder bislang nicht notwendig waren. Ein generischer System Controller ist nun gezwungen, mehrere Funktionen ausfüren zu können, damit er die gewünschten Steuer- und Überwachungselemente zur Verfügung stellen kann. Die Erfassung der im Gerät enthaltenen Daten kann hierbei entweder automatisch oder halbautomatisch erfolgen, wobei letztere Möglichkeit nicht immer vermeidbar sein wird. Der Vorgang könnte oberflächlich betrachtet, relativ einfach aussehen. Der System Controller entdeckt ein unbekanntes Gerät:
Frage: Was bist Du?
Antwort: Ein Entzerrer.
Frage: Wieviele Steuerelemente sind vorhanden?
Antwort: 30 Faderobjekte
Frage: Regelbereiche?
Antwort: Fader1: 20 Hz; +/- 15 dB; 0,5 dB Abstufung// Fader 2: u.s.w.
Anweisung an graphischen System Controller: Generiere mit GUI 30 Faderobjekte. Erstelle entsprechende Steuerpfade. Stimme mit dem Register die Klassenkennung und die Identifikation der entsprechenden Handles ab. Erteile dem Equalizer entsprechende Identifikationsnummer.
Natürlich im Zusammenspiel mit dem Systembuilder, ohne den das nicht möglich wäre. Zur Verdeutlichung noch einmal das bereits eingangs gezeigte Bild. Die eben beschriebenen Vorgänge durchlaufen alle Ebenen im Controller wie auch im zu steuernden Gerät!
Möglicher generischer System Controller
So ähnlich könnte eine generische Erkennung aussehen. Die Schwierigkeiten beginnen eigentlich beim Einholen der Informationen, dem Festlegen der Regelbereiche, dem Erzeugen der Handles, Objektklassen, etc. Diese müssen in jedem Falle unverwechselbar zu dem zu steuernden Gerät gehören. Für einen intelligent programmierten Controller ist das aber keine unlösbare Aufgabe. Trotzdem ergeben sich immer einige Schwierigkeiten. Beispiel: Ein Kombi-Gerät, bestehend aus Delay, Hall, EQ, Kompressor und automatischer Pegelsteuerung soll vom generischen System Controller gesteuert werden. Das heißt, er benötigt hierzu Informationen und Bezeichnungen über die verschiedenen Module, die zugehörigen Steuerelemente, deren Bereiche und die Auflösung. Die Information hierzu – mangels einer entsprechenden Hersteller-Software, muß teilweise erzeugt und teilweise aus den Speichern des Gerätes abgezogen werden. Sicherlich kann der System Controller (weil innerhalb eines PCs ansässig) über bestimmte Informationen verfügen, welche grundsätzlich zur Steuerung der verschiedenen Geräteklassen notwendig sind. Trotzdem muß im zu steuernden Gerätes alles Notwendige abgelegt sein. Die im Gerät enthaltene Intelligenz wird dabei im Durchschnitt erheblich über einer einfachen Steuerung anzusiedeln sein. Wie fast immer: Alles nur eine Frage der Kosten und Stückzahlen.
Zusätzlich muß die Abfrage der Daten natürlich auch noch schnell realisierbar sein. Hohe Datenmengen erzeugen aber innerhalb eines Netzwerk einen Engpaß. Daher sind sicherlich einige Konventionen zu beachten, die innerhalb des generischen Controllers mit geringem Aufwand für die entsprechenden Möglichkeiten sorgen. Denkbar ist in diesem Falle eine Art Bibliothek, die über Steuerobjekte, deren Bereiche und Auflösung verfügt und im Controller grundsätzlich enthalten ist. Eine einzige Kennzahl wäre dann notwendig, um ein Steuerelement aufzurufen. Nachteil: Keine Zukunftssicherheit. Abhilfe: Software Updates – mit allen Vor- und Nachteilen.
Es ist auch als sicher anzunehmen, daß der generische Controller Bestandteil eines normalen System Controllers sein muß. Daher sind alle Firmen, die einen System Controller anbieten, gezwungen, eine allgemeine Anwendung mit vorzusehen.
Schlußbemerkung
Die SC-10-2 Arbeitsgemeinschaft, die den AES-24 Standard während der letzten Jahre kontinuierlich entwickelte, nähert sich der Vollendung. Die hier kurz umrissene Version existiert bereits als vollständiges Protokoll, dessen geringfügige Ergänzungen bis zum Ende Januar 1997 abgeschlossen sind. Nach der Veröffentlichung und der Abwicklung der notwendigen Formalitäten, tritt dieser Standard höchstwahrscheinlich mit der 103. AES Convention 1997 in New York in Kraft.
Die Definition dieses Standards hat sich über mehrere Jahre hingezogen. Der Gründe für immer wieder geäußerte Änderungswünsche waren bessere und umfassendere Erfahrungen und Erkenntnisse mit Steuerungen, sowie einer sich endgültig etablierenden Fixierung des PC-Marktes auf objektbezogene Bedienprogramme und Programmiersprachen. Hierdurch entstand seitens vieler Hersteller ein besseres Verständnis für die eigentliche Bedürfnisse der Anwender. Das Erscheinen immer weiterer proprietärer GUIs mit unterschiedlichsten Anforderungen an die Steuerrechner bzw. Hardware, machten es unabdingbar, mit großem Ernst und Einsatz an die Verwirklichung eines solchen Standards zu gehen. Der Erfolg von MIDI und anderen Standards rechtfertigt hier den gezeigten Einsatz auch ökonomisch.
