Musikproduktion am Computer (15) - PPQ, BPM, und Samplerate (Teil 2)

(Teil 1)

Einschneidende Konsequenzen hat der Unterschied zwischen der Time- und der PPQ-basierten Welt nicht nur für die Rhythmik, sondern für alle möglichen anderen Ebenen. Man braucht ein musikalisches Raster (im Folgenden: Grid), auf dem die Events angeordnet sind, für ganz grundlegendes Editing: Parts müssen auf Taktgrenzen starten und enden, wenn man in die Formverläufe eingreifen will, und Noten müssen sinnvollen musikalischen Punkten zugeordnet sein, wenn man sie verschieben oder quantisieren will - selbst Veränderungen von Lautstärke oder Tonhöhe sind zwar auch ohne Bezug auf ein Grid möglich, fühlen sich dann aber außerordentlich seltsam an.

Time-basierte Audiodateien sind (zunächst) im Tempo nicht veränderbar, und auch wenn zunehmend besser funktionierende Timestrech-Algorithmen diese Limitierung immer mehr aufheben, bleibt es eine heikle Aufgabe, solches Streching so durchzuführen, daß musikalisch sinnvolle Ergebnisse dabei herauskommen. Dabei sind es nicht nur die unvermeidlichen Artefakte, die brauchbare Ergebnisse nur in einem limitierten Rahmen erlauben. Bei jeder (größeren) Tempoänderung ergibt sich die Notwendigkeit, das Material hinterher anzupassen. Wenn man z.B. das Tempo halbiert, werden all die ursprünglich nicht wahrnehmbaren rhythmischen Ungenauigkeiten einer Live-Performance gelegentlich derart dominant, daß man einzelne Noten korrigieren will - und da stößt man in der Bearbeitung eines Audio-Streams auf die nächste (nahezu) unüberwindliche Grenze.

Ganz anders ist dies in der PPQ-Welt: schon die Definition (Pulses per Quarter) macht deutlich, daß man es hier mit einem genuin musikalischen Konzept zu tun hat - die „Ticks” (Pulses), die hier definiert werden, sind bereits so etwas wie ein rhythmischer Puls (wenn auch in einer sehr feinen Auflösung). Die Veränderung des Tempos ist so fest in diesem Konzept verankert, daß man immer beide Informationen braucht, um die absolute Position (z.B. in Millisekunden) eines Events zu beschreiben: nämlich PPQ-Position und das Tempo an dieser Position.

Dies hat zwei Konsequenzen - eine, die eher auf dem technischen Level Probleme mit sich bringt; und eine zweite, die enormen Einfluß auf die ästhetische Gestalt der Musik nimmt, die seit Mitte der 80er zur Popkultur gehört.

Der Tempoverlauf einer Sequenz wird von einer speziellen Spur (Track) beschrieben; in »Cubase« hieß dies früher sehr schön sprechend „Mastertrack”. Die dort abgelegten Events beschreiben entweder absolute Sprünge im Tempo, oder aber einen Anker für einen kontinuierlichen Verlauf. Entscheidend ist hier jedoch, daß sie ihrerseits Timestamps haben, die in PPQ angegeben werden. Das führt zu dem äußerst irritierendem Umstand, daß ihre absolute Position durch die vorangegangen Tempo-Events bestimmt werden, und sie ihrerseits die absolute Position aller nachfolgenden Events festlegen. Wenn der User versucht, sie zu editieren, ist dies relativ problemlos, solange er sich in der PPQ-Welt aufhält. Versucht er dasselbe in einer Time-basierten Umgebung, wird es außerordentlich schwierig, das Editing so zu programmieren, daß die Umgebung sich halbwegs plausibel verhält: mit jedem Verschieben eines Tempo-Events verändern sich nämlich Position und Größe der Parts und Noten, und entziehen der graphischen Darstellung jeden Boden. Wenn man z.B. Drag&Drop so implementieren würde, daß die graphische Darstellung bei jeder Mausbewegung aktualisiert wird (was ja eigentlich selbstverständlich so vom User erwartet wird), hätte man es mit einer ständig flackernden Umgebung zu tun, wo selbst die Position des Mauszeigers sich ständig ändern müßte. - Ich deute das hier nur an; ein Indiz dafür, wie kompliziert dieses Thema ist (obwohl man es mit gerade zwei einander bedingenden Ebenen zu tun hat), findet sich in dem Umstand, daß der Tempotrack in Cubase lange Jahre nur in einem speziellen Editor, nicht aber im Arrange-Fenster zu editieren war.

Der zweite, wesentlich durchschlagendere Effekt besteht freilich darin, daß alles, was man man „live” mit einem Sequenzer-Programm in den Computer einspielt, zwangsläufig immer dem Diktat eines Metronoms unterliegt. Der „Klick” ist hier zwingend, und es gibt letztlich keinen Workaround, mit dem man ihn umgehen könnte - außer, man verzichtet auf jede Möglichkeit musikalischer Nachbearbeitung, beschränkt sich auf Aufdiorecording, und benutzt den Computer als reinen Tonbandersatz. Spätestens, wenn man Audio und MIDI mischt, braucht man ein Recording, das dem Klick folgt. - Dies gilt selbst dann, wenn man sich nur in die Lage versetzen will, in einer reinen Audioproduktion im nachhinein Formverläufe zu verändern, um z.B. einen Refrain nur einmal aufzunehmen, und ihn später durch Copy&Paste an die richtigen Stellen zu setzen.

Der Grund ist recht einfach: man braucht ein musikalisches Raster (s.o.), und das bekommt man nur in der PPQ-Welt - mit der Konsequenz, daß immer das Tempo bekannt sein muß.

Für das Recording bedeutet dies, daß nur ein vorher festgelegtes Tempo es erlaubt, den aufgenommenen Events sogleich eine PPQ-Position zuzuordnen. Im Nachhinein ist dies nämlich nahezu unmöglich - es sei denn, der User ist bereit, mit größtem Aufwand den Tempotrack im nachhinein anzupassen. Es gibt bis heute kein Verfahren, um aus einem Datenstrom, der aus Events mit absoluten Positionen besteht, nachträglich PPQ und Tempo zu berechnen - und dies hat ganz erhebliche Auswirkung auf die Musikkultur der letzten fünfundzwanzig Jahre.

(Teil 3)