Home | Lehre | Videos | Texte | Vorträge | Software | Person | Impressum, Datenschutzerklärung | Blog RSS

Plug-in-Architekturen

Stand: 2012-01-08

Blockweise Verarbeitung, systembedingte Latenz

Digital Audio mit Signalprozessor (DSP): Verarbeitung im Sampletakt möglich; Schnittstellen fest mit Chip verschaltet; theoretisch (!) weniger als ein Sample Latenz möglich; aber ebenso auch Pufferung möglich wie mit Standard-Prozessoren.

Digital Audio auf Standard-Prozessor (PC, Mac, Handy usw.): Task-Wechsel zwischen Oberfläche und Signalverarbeitung (auf Multicore eigentlich nicht mehr nötig!), gemeinsam genutzte Busse, keine festen Zeiten für Befehlsausführung. Deshalb Arbeit in Zeitscheiben = Datenblocks. Signalverarbeitungsalgorithmus erhält Datenblock (ggf. außer bei Synthese) und gibt Block mit berechneten Daten zurück. Ringpuffer (Circular Buffer) für Eingangssignale und für Ausgangssignale, denn Eingangsdaten erst verwendbar, wenn Blockgröße erreicht, und Ausgangsdaten dürfen nicht leerlaufen. Problem: Überlauf des Eingangspuffers, Leerlaufen des Ausgangspuffers. Latenz: mindestens die Dauer eines Blocks, aber so wenig wäre zu riskant.

Hardware und Treiber zur Ein-/Ausgabe erhöhen die Latenz noch.

ASIO: Ringpuffer für Ein- und Ausgabe sind starr verkoppelt und haben nur zwei Slots (double buffering). Beispielprogramm. Latenzmessung.

Samplitude Hybrid Audio Engine: Der Aufwand für einen Audioalgorithmus ist typischerweise proportional zur Zahl der Samples. Der Aufwand für das Organisatorische (Verabeitungsfunktion aufrufen, Werte übergeben) ist dagegen typischerweise proportionale zur Zahl der Blöcke. Also sind längere Blöcke effizienter, denn bei gleicher Zahl an Samples braucht man dann weniger Blöcke. Aber längere Blöcke verlängern die Latenz. Idee: Spuren, die bereits aufgezeichnet sind, latenzkompensieren und mit großen Blöcken verarbeiten; Echtzeitsignale mit kurzen Blöcken verarbeiten. Demo mit Samplitude.

Plug-ins: Grundsätzliches

Plug-ins (die Sammlung: KVR) verpacken Signalverarbeitungsalgorithmen plus grafische Bedienoberflächen in austauschbare Module, selten für DSPs wie Digidesign TDM, Sonic Core (vorher CreamWare) Scope, typischerweise für Standard-Prozessoren („Native Signal Processing“). Die üblichen Standards für Letzteres sind VST, RTAS, AU, DX und Externals für Max/MSP.

Die meisten Plug-ins funktionieren auf eine von drei Weisen:

Plug-ins können als Insert- oder als Send-Effekte platziert werden. Als Insert-Effekte benötigen sie aber vielleicht einen Dry/Wet-Regler. Im Prinzip kann man auch eine komplette andere Audio-Software ähnlich einhängen wie ein Plug-in, siehe ReWire (nur für lizenzierte Entwickler verfügbar).

Hosts und Kommunikation

Programme, die Plug-ins aufrufen können, sind Hosts. Dazu zählen die großen DAW-Programme ebenso wie etwa VSTHost von Hermann Seib. Plug-ins können auch offline laufen (siehe den VST Enabler, ein VST-Host für Audacity), dann aber auch schneller als in Echtzeit. Man füttert sie einfach mit Datenblöcken, so schnell es geht. Mehrere Instanzen eines Plug-ins können gleichzeitig laufen. Demos: VST Optimizer, MIDI Waveform Editor. Andere unkonventionelle Hosts sind zum Beispiel Wrapper, die ein Sorte Plug-in hosten, selbst dann aber eine andere Sorte Plug-in sind (Beispiel: VST to RTAS Adapter).

Datenformate für die Ein- und Ausgabedaten: Ganzzahlig (16/24/32 Bit), Gleitkomma (32/64 Bit). Gleitkomma hat riesigen Umfang (kein Overload) und eine Genauigkeit, die prozentual zum Signal gleicht bleibt. Ganzzahlige Daten sind schneller zu verarbeiten und haben bei gleicher Breite nahe ihrer Übersteuerungsgrenze eine höhere Auflösung als Gleitkommadaten.

Die Regler auf der grafischen Bedienoberfläche lassen sich per Hand bedienen, lassen sich aber auch automatisieren. Der Host muss dazu Meldungen über Regleränderungen vom Plug-in erhalten, diese aufzeichnen und später wieder dem Plug-in zuspielen. Der Host kann die Namen der Parameter vom Plug-in abfragen, um die zum Beispiel in einem Kurveneditor anzuzeigen. Ebenso kann der Host eine ganz eigene grafische Oberfläche statt der originalen grafischen Oberfläche des Plug-ins zeigen und dem Plug-in dann die Einstellungen senden.

Die meisten Plug-in-Standards sehen nicht vor, dass ein Plug-in ein weiteres Audiosignal neben dem eigentlichen erhält. Um z.B. einen Sidechain-Kompressor zu realisieren, kann man notfalls aus dem Eingangssignal und dem Steuersignal durch Verschaltung in der DAW ein künstliches Quadro-Signal machen. Alternativ kann das Plug-in so programmiert sein, dass man es sowohl auf der Spur des Eingangssignals wie auf der Spur des Steuersignals platziert (Beispiel); diese beiden Instanzen können dann unter sich kommunizieren.

Effektbedingte Latenz, Latenzkompensation

Die meisten Effekte und Instrumente können den jeweils zurückzugebenden Datenblock direkt mit aktuellen Werten füllen. Es entsteht dann keine zusätzliche Latenz. Anders ist es etwa bei Look-Ahead-Kompressoren, Pitch-Shiftern (FFT!) oder bei linearphasigen EQs. Diese brauchen eine Möglichkeit zu Vorausschau oder verlangen eine Mindestmenge an Daten, können also erst später die aktuellen Daten ausgeben. Damit diese Spuren nicht hinterherklappern, kann man die anderen per Hand oder automatisch nach hinten schieben (Latenzkompensation, Delay Compensation). Die Automatik verlässt sich dabei auf die Verzögerung, die ihr das Plug-in meldet. Diese Angabe muss allerdings nicht stimmen.

Standards für Plug-ins

Dies ist nur eine Auswahl!

VST Virtual Studio Technology (Steinberg, 1996). Nativ. Daten in 32 oder (selten) 64 Bit Gleitkomma. Latenz abfragbar. VST 2.0 (1999): MIDI-Daten an Plug-ins (VST Instrument, VSTi). VST MIDI Effects (2002): MIDI-Plug-in-Effekte. VST 2.4 (2006): optional 64 Bit Gleitkomma. VST 3.0 (2008) dynamische Konstellationen an Ein- und Ausgangskanälen, automatisches Schlafen, wenn kein Eingangssignal, Sample-genaue Automatisierung. Demo von VST 2.x mit Plugin Consultant.

Max/MSP Externals (Cycling '74, 1997). Nativ. 32 Bit Gleitkomma. Anzahl Ein-/Ausgänge beliebig. Effekte, Instrumente, MIDI (Messages). Keine Information über Latenz.

TDM Time Domain Multiplex (Digidesign 1997). DSP. Audiodaten in 24 Bit. Nur für lizenzierte Entwickler. Effects und Instruments.

RTAS Real-Time Audio Suite (Digidesign 1999). Nativ. Daten in 32 Bit Gleitkomma. Nur für lizenzierte Entwickler. Effects und Instruments.

DX DirectX Plug-in (Microsoft/Cakewalk 2001). Nativ. Nur Windows. Daten standardmäßig in 32 Bit Gleitkomma. Anzahl Ein-/Ausgänge beliebig. Effects und Instruments (DXi).

AU Audio Unit (Apple, 2004). Nativ. Nur Mac OS X. Daten standardmäßig in 32 Bit Gleitkomma; andere prinzipiell möglich. Anzahl Ein-/Ausgänge beliebig. Effekte oder MIDI-gesteuerte Instrumente oder MIDI-gesteuerte Effekte. Meldung über Latenz.

ARA Audio Realtime Access (Celemony/Presonus, 2011). Nativ. Voller Zugriff auf alle Audiodaten, nicht nur der aktuelle Block. Voraussetzung, komplexe Software wie Celemony Melodyne komplett (auch grafisch!) in DAWs zu integrieren. Bisher musste man das Material quasi in das Melodyne-Plug-in überspielen.

AAX Avid Audio eXtension (Avid Audio, 2011). Native und DSP getrennt unterstützbar. Plug-ins mit exakt gleichem Resultat für Native und DSP möglich.