In Teil 1 (HIER KLICKEN) haben wir gesehen, wie eine Werkzeugkette aussieht, mit der man aus einer Textdatei mit Noten und einer Konfigurationsdatei automatisiert ein Notationsvideo mit einem passablen Backingtrack erzeugen kann.

Das Ganze geht mit diversen Open-Source-Programmen und einem Koordinationsprogramm namens LilypondToBandVideoConverter [LTBVC] auf der Kommandozeile, aber es ist etwas wenig interaktiv.

Eine naheliegende Idee ist natürlich, das interaktive Arbeiten in einer DAW zu kombinieren mit den Möglichkeiten dieser Werkzeugkette.

Genau das werde ich im Folgenden tun und das Vorgehen am Beispiel der DAW Reaper beschreiben. Aber man kann das in ähnlicher Form auch für andere DAWs machen, sofern sie eine passende Programmierschnittstelle haben und man die vorgestellten Skripte dorthin portiert.

Dafür werden nochmals die Schritte aus dem ersten Teil betrachtet und daraufhin analysiert, wie man dabei die DAW intelligent nutzen kann. Insbesondere werden dazu Skripte [LTBVC-Plugins] und Plugins [SoXPlugins] verwendet, die ich erstellt und auf GitHub verfügbar gemacht habe.

Als Beispiel dient wiederum den Demosong aus dem 1. Teil. Über den obigen GitHub-Link findet man das zugehörige Demoprojekt für Reaper, das wir in diesem Teil benutzen werden.

Strukturierung des Projekts

Wir erfassen die Noten für die vier Stimmen (bass, vocals, guitar, drums) in je einer Spur der DAW, teilen aber die Noten innerhalb der Spuren in Fragmente auf.

Um uns einfach auf der Zeitachse orientieren zu können, definieren wir Bereiche (“Regionen”) für Intro, Verse 1 und 2 sowie das Outro. Das ist normalerweise per Fingerschnipp zu erledigen, aber wir nutzen ein einfaches Skript, das diese Regionen aus einer Strukturspur ableitet.

Erfahrungsgemäß kann man einfach schneller MIDI-Items auf einer Spur kopieren, verschieben, umbenennen oder einfärben als Regionen entsprechend zu manipulieren. Daher bauen wir uns eine Strukturspur und generieren per Aktion MakeRegionsFromRegionStructureTrack daraus die Regionen. Die Position, Namen und Farben werden aus den MIDI-Items in die Regionen übernommen (siehe Bild 1).

Man erkennt recht gut die sehr simple Struktur des Demosongs.

Noteneingabe — Phasen “extract”, “score” und “midi”

Der Beispielsong besteht aus diversen gleichartigen Teilen, wie man ja auch schon in Teil 1 erkennen konnte. Wir erstellen die Noten wie gewohnt und erzeugen Aliase (“pooled items”) für gleiche Notenfragmente, damit sich diese auch synchron ändern, wenn man eines der Fragmente aus der Gruppe ändert. Die Noten im Bass für Vers 1 und Vers 2 sind identisch, dort wird also ein Original und ein Alias verwendet. Bild 2 zeigt, wie das aussehen kann.

Da aber die Werkzeugkette ja stark auf Lilypond [Lilypond] als Notensatzsystem setzt: wie kommt man jetzt zu den Einträgen für die Lilyponddatei? Muß man die irgendwie händisch abtippen? Nein, dafür gibt es wiederum ein Skript namens ExportLilypond, das für ein selektiertes Notenfragment die zugehörige Lilypondrepräsentation erzeugt.

Die Noten werden in englischer Notation erzeugt (das passt zur Konvention der externen Werkzeugkette aus Teil 1). Das heißt, ein f♯ (f sharp) wird als “fs”, ein e♭ (e flat) wird als “ef” notiert. Der Algorithmus analysiert die MIDI-Noten aus dem Notenfragment entlang der Takte und gruppiert sie in die kleinstmögliche Zahl von Noten, die konform zu gängigen Notationsrichtlinien sind. Akkorde werden dabei auch automatisch erkannt und korrekt notiert.

Jede Note wird dabei so in (gebundene) Teilnoten aufgeteilt, dass diese an Rasterpositionen eines Taktes liegen, an denen sie nach diesen Notationsrichtlinien liegen dürfen. Das führt manchmal zu scheinbar seltsamen Aufteilungen, wie man in Bild 3 erkennt. Bild 3a zeigt die Originalsequenz, Bild 3b die Aufteilung durch das Skript gemäß Notationsrichtlinien.

Die für das Lilypondfragment gewählte Startoktave ist abhängig vom Namen des Fragments, weil dieses den Namen des Instruments angeben sollte. Beispielsweise beginnt die Lilyponddarstellung eines Gitarrenfragments mit dem Lilypondtext relative c' (= C₃, eingestrichenes c), die Lilyponddarstellung eines Bassfragments mit relative c, (= C₁, großes c).

Wenn man das Skript auf den Vers der Bassstimme anwendet, erhält man das Ergebnis auf Bild 4. Bei einer Schlagzeugspur wird automatisch die Schlagzeugnotation verwendet (siehe Bild 5).

Man erkennt im Vergleich zur Notation im ersten Teil, dass etwaige Notenwiederholungen nicht automatisch generiert werden (z.B. steht da sechs mal d8 statt repeat unfold 6 {  d8  }); das müsste man in einer manuellen Nachbearbeitung korrigieren.

Es ist auch nützlich, diese in die DAW eingegebenen Noten zu normieren. Beispielweise möchte man sie später mit der generierten MIDI-Datei vergleichen (damit man sehen kann, was der Algorithmus zur Humanisierung so alles angestellt hat).

Diese Normierung erreicht man dadurch, dass man auf diese Spuren das Skript normalizeStructuredVoiceTracks anwendet; es durchsucht alle strukturierten Stimmspuren (die es anhand einer Namenskonvention identifiziert) und setzt dort alle MIDI-Anschlagstärken (“velocities”) auf den Standardwert 80, quantisiert die Noten auf lilypond-kompatibles Raster und löscht alle MIDI-Steuercodes für Panorama, Lautstärke und Hall, weil diese Einstellungen später durch die Konfiguration bestimmt werden sollen.

Man bekommt also so relativ schnell die Noten zusammen für die Lilyponddatei und kann damit sowohl die Stimmauszüge als auch die Partitur, das stumme Video und die MIDI-Datei erzeugen.

Abgleich der DAW-Noten mit der generierten MIDI-Datei — Phase “midi”

Da man in der Lilyponddatei aber immer noch an den Noten schrauben wird (beispielsweise um gemeinsame Teile herauszuziehen oder die Wiederholungen intelligenter zu notieren), könnte es sein, dass das Notenmaterial aus der DAW nicht mehr hundertprozentig mit der generierten MIDI-Datei zusammenpasst.

Außerdem gibt es durch die Humanisierung in der MIDI-Datei auch noch Unterschiede zu den normierten Noten in der DAW, sie sind aber in der Regel sehr gering. Wenn man die externe Werkzeugkette kontrollieren will, so sind also hauptsächlich massive Abweichungen interessant (beispielsweise dass nach der Generierung eine Note in der falschen Oktave liegt oder die Ablaufstruktur des Songs komplett zu der in der DAW auseinanderläuft).

Man könnte dazu natürlich die durch den ltbvc generierte MIDI-Datei immer wieder in das Projekt in der DAW importieren. Das ist aber mühsam, insbesondere falls die MIDI-Spuren im Projekt auch noch frei verteilt sein sollten. Wenn man aber den Import einmal gemacht hat, dann hilft ein Skript namens ImportMidi, mit dem der erneute Import massiv erleichtert wird.

Die vom ltbvc erzeugte MIDI-Datei hat eine vorhersagbare Struktur und Namenskonvention für die Spuren. Das Skript durchsucht das Projekt nach Spuren gemäß dieser Konventionen: Spuren mit einem MIDI-Item, dessen Name auf “.mid” endet und mit Stimmnamen und MIDI-Dateinamen beginnt.

Das Skript macht insgesamt folgendes: es liest die zugehörige MIDI-Datei in temporäre Spuren ein, aktualisiert bestehende Spuren mit den passenden Namen und löscht dann die temporären Spuren. Bei den aktualisierten Spuren werden alle MIDI-Steuercodes für Panorama, Lautstärke und Hall entfernt, weil diese Einstellungen später durch die Konfiguration bestimmt werden sollen. Abschließend werden diese Spuren auch noch gegen versehentliche Änderungen gesperrt (sie sollen ja nur gelesen oder erneut importiert werden).

Für die vier Stimmen des Demosongs brauchen wir vier MIDI-Spuren. Bild 6 zeigt die Spuren und die MIDI-Items mit den entsprechenden Namen im Reaper-Demoprojekt.

Wenn man diese Spuren importiert hat, dann kann man in einer DAW in der Regel einen Abgleich machen zwischen den strukturierten Stimmspuren von oben und den importierten MIDI-Spuren der externen Werkzeugkette. Das geht beispielsweise in Reaper dadurch, dass man für eine strukturierte Stimmspur den MIDI-Editor startet und dazu die entsprechende Spur der MIDI-Datei zum Vergleich auswählt.

Bild 7 zeigt einen derartigen Abgleich zwischen einer strukturierten Bassspur und der zugehörigen generierten MIDI-Spur. Zur Demonstration wurden in der strukturierten Bassspur willkürlich einige Noten verschoben, nachdem die Noten in die externe Werkzeugkette übertragen worden waren: man erkennt gut, dass die Spuren jetzt nicht mehr deckungsgleich sind (die verschobenen Noten sind rot, die generierten Noten grün umrandet).

Zwischenstand (nach Phase “preprocess”)

Wir haben die erste Hälfte der Bearbeitungsphasen abgedeckt (siehe Bild 8). Mit einer DAW können wir eingegebene Noten nach Lilypond exportieren (via “exportLilypond”), die strukturierten Stimmspuren bereinigen (via “normalizeStructuredVoiceTracks”) und auch die generierte MIDI-Datei schnell importieren, um sie mit den Daten der DAW abgleichen zu können (via “importMidi”).

Allerdings sind wir bisher nur zur MIDI-Datei und zur stummen Videodatei gekommen. Jetzt stellt sich also die Frage, wie die Audiogenerierung aussehen kann. Ziel muss sein, dass das Ergebnis in der DAW so nah wie möglich an — idealerweise deckungsgleich mit — dem Ergebnis der externen Werkzeugkette auf der Kommandozeile ist.

Die Idee ist, dass Plugins in der DAW aus den MIDI-Daten Audiodaten erzeugen und auf ihnen Effekte anwenden in eine Form, die der externen Werkzeugkette entspricht.

Ob und wie das geht, sehen wir in den folgenden Abschnitten.

Generierung von Audio aus MIDI-Noten — Nachbildung der Phase “rawaudio”

Naja, es sollte nicht allzu schwer sein, in einer DAW aus einer MIDI-Spur Audiosignale zu erzeugen.

Prinzipiell ist das richtig: man versieht den MIDI-Track mit einem Plugin (beispielsweise einem VSTi-Plugin), das MIDI verarbeiten kann und Audio liefert. Und fertig.

Aber wir wollen ja nicht irgendein generiertes Audiosignal, sondern eines das weitgehend identisch zu der Audiodatei ist, die das Programm fluidsynth [Fluidsynth] in der Werkzeugkette mit Hilfe eines Soundfonts erzeugen würde.

Leider stellt sich heraus, dass es ein derartiges Plugin nicht gibt. Relativ nah dran ist ein einfaches VSTi-Plugin namens “FluidSynthVST” [FluidVST]: es ist aber leider relativ sperrig zu bedienen, hat eher prototypischen Charakter und wird offenbar seit mehreren Jahren nicht mehr weiterentwickelt.

Es gibt auch — meines Wissens nach — kein anderes Plugin, das sowohl in einer DAW als auch direkt in einer Kommandozeilenversion nutzbar wäre.

Außerdem gibt es prinzipielle Probleme: wenn ein Soundfont irgendwelche Modulatoren benutzt, dann werden die eines Plugins niemals synchron sein mit denen in einer externen Werkzeugkette. Darüber hinaus verarbeiten Plugins Audiodaten mit einem bestimmten Raster (die Pufferlänge, also beispielsweise 64 Samples); wenn internes und externes Raster nicht absolut deckungsgleich sind, dann wird das erzeugte Audiosignal niemals identisch sein. Und das passiert schon dann, wenn die Startposition beim Abspielen in der DAW nicht auf einer Rasterlinie der externen Generierung liegt.

Ähnliche Phänomene haben wir im Folgeabschnitt, dort diskutieren wir das noch etwas genauer.

Also: eine bitidentische Erzeugung von Audio aus MIDI im Vergleich zum Kommandozeilenprogramm fluidsynth ist nicht realistisch umsetzbar.

Für eine annähernde Emulation von fluidsynth verwende ich einfach ein gängiges Plugin, das gut genug ist: sforzando [Sforzando], ein VST3i-Plugin, das statt Soundfonts sogenannte SFZ-Dateien verwendet (die aber 1:1 aus Soundfonts erzeugt werden können, z.B. aus dem FluidR3-Soundfont [SFFluid]).

Das heißt: eine MIDI-Spur (oder eine strukturierte Stimmspur) bekommt als ersten Effekt sforzando und dort wird als Klang genau das MIDI-Instrument ausgewählt, das auch für die jeweilige Stimme in der Konfigurationsdatei angegeben wurde. Steht dort beispielsweise als MIDI-Instrument für die Bassstimme eine 35, dann wird in sforzando ein “Fretless Bass” aus demselben Soundfont ausgewählt. Bild 9 zeigt die Konfiguration von sforzando gemäß der Konfigurationsdatei für alle Stimmen des Demosongs.

Effekte aus SoX als Plugins — Nachbildung der Phase “refinedaudio”

Okay, wenn wir schon die MIDI-Noten nicht bitidentisch zur externen Werkzeugkette in rohe Audiodaten übersetzen können, dann ist das mit den SoX-Effekten aus der Nachbearbeitungsphase bestimmt hoffnungslos. Für SoX [SoX] gibt es ja keine DAW-Plugins — es ist halt ein Kommandozeilenprogramm — und irgendwelche Effekte von anderen Herstellern sind natürlich niemals bitidentisch zu diesen Kommandozeileneffekten.

Komplett aussichtslos. Mist.

Bis vor zwei Jahren war die Situation auch genauso, aber weil ich wirklich in der DAW genau nachbilden will, was auf der Kommandozeile passiert, habe ich für die Brot-und-Butter-Effekte von SoX eigene VST3-Plugins geschrieben [SoXPlugins], die auf den gängigen Plattformen laufen und frei verfügbar sind (für Windows, MacOSX, Linux). Sie sind auch relativ effizient, damit auch größere Effektketten in der DAW laufen können, ohne sie in die Knie zu zwingen.

Abgedeckt werden die SoX-Effekte allpass, band, bandpass, bandreject, bass, biquad, compand, equalizer, gain, highpass, lowpass, mcompand, overdrive, phaser, reverb, treble und tremolo. Sie werden kombiniert in sechs VST-Plugins: Multiband-Compander, Filter, Gain, Overdrive, Reverb und Tremolo/Phaser.

Alle ihre Parameter können über Schiebesteller eingestellt werden und deren Bereiche sind identisch zu denen der SoX-Effekte auf der Kommandozeile. Das ist manchmal etwas gewöhnungsbedürftig, weil beispielsweise die Threshold beim Compander minimal bei -128dB liegen darf oder der Gain beim Phaser bei maximal 1000, aber das ist eben gewollt. Bild 10a zeigt die Oberfläche des SoX-Phasers, Bild 10b die eines Bandes in einem SoX-Multiband-Companders.

Ziel dieser Plugins ist also nicht, tolle Effekte bereitzustellen, sondern die Effekte aus SoX perfekt nachzubilden.

Obwohl diese Plugins komplett neu implementiert wurden, liefern sie bei jeder Parameterkombination identische Ergebnisse zum existierenden SoX-Effekt auf der Kommandozeile. Um das zumindest stichprobenartig zu überprüfen, gibt es in dem Softwarepaket ein Testprojekt, in dem für alle oben erwähnten SoX-Effekte per Kommandozeile gerenderte Audiofragmente mit in Echtzeit über die SoX-Plugins berechneten Audiodaten verglichen werden. Das macht man, indem man intern und extern erzeugtes Audio addiert, aber einen der Partner um 180° phasenverschiebt (ein sogenannter “Null-Test”). Sie löschen sich praktisch vollkommen aus, das heißt: sie sind identisch. Ganz genau genommen haben sie bei einer Spektralanalyse eine Abweichung von unter -150dB, das hört man nur mit goldenen Ohren 😉 (siehe Bild 11).

Ha, Pluginmeister, jetzt habe ich Dich doch bei einer Lüge erwischt: Du hast doch zwei Modulationseffekte Tremolo und Phaser; die laufen intern mit Sicherheit nicht synchron zu irgendeiner externen Effektkette, also nix mit bitidentisch, oder?

Das ist prinzipiell richtig überlegt — und das hatten wir schon oben bei der Audiogenerierung aus MIDI-Daten —: wenn ein extern erzeugter Audioschnipsel mit Modulation an irgendeiner Stelle im Projekt liegt, dann wäre eine Modulation eines entsprechenden Plugins nur zufällig deckungsgleich, sondern sie ist in der Regel phasenverschoben. Das liegt daran, dass Plugins genau dann mit ihrer Modulation beginnen, wenn die Wiedergabe gestartet wird. Das heißt, deren Phase 0° der Modulation liegt auf dem Startzeitpunkt des Abspielens.

Bild 12 zeigt die Situation an einem Beispiel. Wir gehen hier von einem Tremoloeffekt aus, der auf ein Fragment in einer Audiospur angewendet wird, die zum Zeitpunkt t_fragment in der DAW startet. Außerdem solle die Wiedergabe in der DAW zum Zeitpunkt t_play beginnen. Wie man sich leicht überlegen kann, hat die Modulation beim extern prozessierten Fragment (bei dem der Originalschnipsel einfach mit einem Tremoloeffekt versehen wurde) genau zum Zeitpunkt t_fragment ihre Phase 0°. Beim internen Effekt der DAW ist die Phase 0° jedoch zum Zeitpunkt t_play (siehe die roten Punkte in den jeweiligen Spuren, die die Phase 0° kennzeichnen). Dies würde zu massiven Abweichungen zwischen extern und intern generierten Audio führen.

Aber es läßt sich dadurch beheben, dass man beim internen Effekt einstellt, zu welchem Zeitpunkt die Modulationsphase 0° sein soll (sogenanntes “time­locking”). Stellt man diesen Parameter auf t_fragment ein, dann sind die Modulationen synchron (wie man beim Vergleich der zweiten mit der untersten Spur erkennen kann). Der Effekt läuft natürlich schon bei t_play los, seine Modulationsphase ist aber so versetzt, dass sie exakt bei t_fragment die Phase 0° erreicht.

Bild 13 zeigt, wie beispielsweise beim SoX-Tremolo-Effekt die Referenzzeit eingestellt werden kann. Der Parameter Time Offset wird auf den obigen Zeitpunkt t_fragment eingestellt (wir nehmen im Bild an, dass dies die Position 324,0s ist), um dann synchron zur externen Modulation zu sein.

Wenn man die externe Effektkette in SoX und die interne in der DAW aus den SoX-Plugins mit denselben Einstellungen versieht, gegebenenfalls die obigen Zeitversätze einstellt, gibt es keinerlei Abweichung zwischen externen und internen Audiodaten (ganz genau liegt sie unterhalb von -150dB, siehe oben; das ist also absolut unhörbar).

Hmm, auch das ist ein bißchen gelogen. Man kann manchmal beim Null-Test Abweichungen in Form von Knacksern hören: dann gab es ein digitales Clipping im externen SoX-Programm, das bei den DAW-Plugins nicht auftritt. Diese rechnen — im Gegensatz zu SoX — nicht mit 32Bit-Ganzzahlen, sondern mit Gleitkommaarithmetik. Das externe SoX-Programm signalisiert aber dieses Clipping im Fehlerprotokoll; man muss also einfach die Effektparameter entsprechend anpassen, um das Clipping komplett zu vermeiden.

Mischen und Video mit Audiotracks — Phasen “mix” und “finalvideo”

Für das Mischen der Audiospuren brauchen wir in einer DAW keine besonderen Funktionen: wenn wir die Stimmen in einzelnen DAW-Spuren haben, dann kann ihr Anteil am Gesamtmix über Fader definiert werden, die man entsprechend zu den Werten in der Konfigurationsdatei einstellt.

Und das stumme Video kann auch oft in die DAW in einer eigenen Spur abgelegt werden — Reaper kann das beispielsweise —, damit man kontrollieren kann, wie gut es mit den Audiospuren zusammenpasst.

Was wir nicht haben, sind die Untertitel für die Taktnummern. Sie sind aber entbehrlich, denn in einer DAW haben wir ja sowieso einen Zähler mitlaufen, der auch Taktnummern anzeigen kann.

Abschließendes Fazit

Wir sind durch!!

In Teil 1 haben wir gesehen, wie man aus einer Textdatei in Lilypond für ein Arrangement und eine Konfigurationsdatei mit dem LilypondToBandVideoConverter vollautomatisch Stimmauszüge, Partitur, MIDI-Datei, Audiodateien mit Effekten und schließlich auch Notationsvideos erzeugen kann. Das Verfahren läuft komplett auf der Kommandozeile mit Hilfe von gängigen Open-Source-Programmen und eben dem LilypondToBandVideoConverter.

Es ist etwas mühsam, liefert aber brauchbare Ergebnisse.

In Teil 2 wurde dann gezeigt, dass man dieses Vorgehen, das eher ein klassischer “Edit-Compile-Run-Ansatz” auf der Kommandozeile ist, durch die Interaktion mit einer DAW sinnvoll ergänzen kann (siehe Bild 14). Man kann

• die Noten in der DAW selbst erfassen und in Textfragmente für Lilypond übersetzen (via “exportLilypond”),
• schnell die extern generierte und humanisierte MIDI-Datei mit den Noten in der DAW abgleichen (via “importMidi”),
• für die externe Effektkette mit SoX entsprechende DAW-Plugins verwenden (“SoXPlugins”), die bitidentische Audiodaten liefern und
• natürlich immer simple Dienste der DAW nutzen (wie beispielsweise das Mischen verschiedener Stimmen über die Lautstärkesteller der DAW).

Eine Lücke gab es allerdings bei der Arbeit mit der DAW, weil es kein Programm gibt, das sowohl auf der Kommandozeile als auch in der DAW in identischer Weise MIDI-Daten in Audiodaten transformieren kann (im Bild mit “???” markiert). Hier muss man sich behelfen und die leichten Abweichungen zwischen externer Werkzeugkette und DAW in Kauf nehmen.

Schlußbemerkung

Wer bis hier durchgehalten hat, hat meine absolute Hochachtung: er hat sich in den beiden Teilen des Workshops ein sehr weitgehendes und komplexes Vorgehen angesehen, um Musikarrangements und passende Notationsvideos zu machen, aber zugegebenermaßen eben auch ein ziemlich nerdiges (daher ja auch der Titel dieses Workshops).

Für mich klappt der Ansatz prima; vielleicht kann ja irgendjemand damit etwas für sich selbst anfangen oder zumindest Teile davon klauen.

Über eine entsprechende Rückmeldung würde ich mich freuen!