24.10.2011

Netzwerkprodukte - Userinterfaces (6)

(Themenanfang)

Ein Sequenzer, der MIDI wie auch Audio behandeln und gemeinsam abspielen will, steht vor dem Problem, daß es sich um sehr unterschiedliche Medien handelt, die immer wieder nach Sonderbehandlung vernehmlich rufen: MIDI basiert auf PPQ (und ist damit unabhängig vom Tempo); Audiodateien sind „timebased“ und laufen zunächst unabhängig vom eingestellten Tempo; etc., ich hatte das Thema schon ausführlicher behandelt.

Auch in der „Philosophie“ bei der Wiedergabe gibt es einen gewichtigen Unterschied: ein Audio-Track im Sequenzer entspricht idR. einem Kanalzug auf dem virtuellen Mischpult, während MIDI dort zunächst überhaupt nicht auftaucht. „Lautstärke“ ist ein Attribut, das man Audio nachträglich hinzufügt (indem man den „Stream“ gewissermaßen filtert, und jedes Sample, abhängig von der Stellung des Volume-Reglers auf dem Mischpult, skaliert). In der MIDI-Welt ist Lautstärke hingegen zunächst ein Attribut der einzelnen Noten (Velocity) – auch MIDI-Volume (Controller 7 und 11) kommt nicht „von außen hinzu“, sondern ist Teil des Datenstroms selbst.

Das ist historisch begründet, und nicht per se „gutes Design”. Man kann die Welten aus MIDI und Audio jedoch zumindest auf dieser Ebene nachträglich einigermaßen gut miteinander „verheiraten”: MIDI-Tracks bekommen z.B. einen Kanal im Mixer, der MIDI-Volume ausspuckt (wobei er dann regelmäßig in Kollision mit dem MIDI-Volume gerät, das der User im Track selbst abgelegt hat).

Diese unterschiedlichen Ansätze führen zu weiteren Konsequenzen. In der MIDI-Welt ist es z.B. kein Problem, mehrere Datenströme (z.B. in Form von „Parts“ in Cubase) auf demselben Track übereinander zu stapeln und gemeinsam abzuspielen. Bei Audio-Daten geht das nicht: hier geht genau eine Datei zur selben Zeit an den Ausgang. Wenn man mehrere Audio-Dateien auf demselben Track übereinanderstapelt, „gewinnt“ immer die, die „oben“ liegt; der Rest bleibt stumm. - Das hat wieder historische Ursachen; vergl. oben.

Die Tatsache, daß es eine „Hierarchie“ von Audio-Dateien auf demselben Track gibt, kann man fruchtbar machen, wenn es darum geht, aus mehreren Aufnahmen desselben Takes – aus mehreren, unmittelbar aufeinander folgenden Aufnahmen derselben Passage – die „beste“ Version zusammenzuschneiden. Der Sänger hat im ersten Take die Töne in Takt eins und zwei richtig, im nächsten sind die in Takt drei und vier besser: man schneidet innerhalb der „Lanes“ desselben Tracks, aktiviert jene Lanes, die am besten gefallen, und verläßt sich darauf, daß der Rest des Materials automatisch stumm ist. Wie gesagt: auf einem Audiotrack kann immer nur eine Audiodatei gleichzeitig spielen. Wenn man eine Datei (oder einen Ausschnitt davon) „nach vorne holt“, kommt der Rest automatisch zum Schweigen.

Dieses Konzept von „Lane-Editing“ (oder „Comping“) hat auf den ersten Blick eine Reihe von Vorteilen, die von den Usern auch erkannt und ausgiebig genutzt werden. Sie rasseln dann aber in Probleme, wenn sie das Feature für Aufgaben benutzen, für die es anfangs gar nicht konzipiert war. So gibt es regelmäßig Situationen, wo man nicht einfach zwischen den Versionen mehrerer Takes hin- und herschalten kann, ohne daß die Takes überlappen. Im Beispiel oben sind die ersten beiden Takte des Sängers vielleicht perfekt, haben aber am Ende einen langen Ton, den man nicht einfach abschneiden kann, wenn man in die beiden nächsten Takte auf dem anderen Take wechseln will. - Ich deute das nur an; wenn es um Take-basiertes Editing von Sprachaufnahmen (die keinem Taktmaß folgen) geht, landet man in noch ganz anderen Problemen.

Worauf ich hinaus will: es gibt in den meisten Programmen Features, die nur historisch begründet sind, und mit den Problemen, die ihre User lösen wollen, gar nichts zu tun haben. Das Konzept der „Lanes“ z.B. kommt vom Versuch, die ursprünglichen Limitierungen bei der Wiedergabe von Audiomaterial im Userinterface fruchtbar zu machen. Die User sehen das ganz anders: sie haben ein Problem, das man in der ursprünglichen Version des Features nicht recht lösen kann, und verlangen Nachbesserungen, selbst wenn die regelmäßig deutlich über die technischen Limitationen des ursprünglichen Designs hinaus weisen. Dann wird von den Entwicklern oft genug nachgebessert, bis ein Grad an Komplexität im Code (aber auch im Userinterface) entsteht, den keiner mehr recht versteht bzw. beherrscht.

(Wer übrigens der Meinung ist, dies sei ein Cubase- bzw. Steinberg-spezifisches Problem, sollte mal versuchen, Adobe Photoshop zu lernen.)

(Kommentarfunktion z.Zt. deaktiviert.)