Workshop – Produce Like a Nerd (2): Kann man alles auch mit der DAW machen, oder?
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'
(= C3, eingestrichenes c), die Lilyponddarstellung eines Bassfragments mit relative c,
(= C1, 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 tfragment in der DAW startet. Außerdem solle die Wiedergabe in der DAW zum Zeitpunkt tplay 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 tfragment ihre Phase 0°. Beim internen Effekt der DAW ist die Phase 0° jedoch zum Zeitpunkt tplay (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 “timelocking”). Stellt man diesen Parameter auf tfragment 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 tplay los, seine Modulationsphase ist aber so versetzt, dass sie exakt bei tfragment 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 tfragment 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!
Abgefahren Fredi :) Ich automatisiere mir mittels Scripter oder was auch immer ja schon viele Routine Aufgaben in Logic und MacOS weg. Aber das hier ist krasses Zeug.
Mich würde interessieren ob man in deinem Ansatz auch Interaktion mit Sensoren und Aktoren erzeugen könnte?
@TobyB Hallo TobyB,
schön, von Dir zu hören!
Du schreibst:
> [Automatisierung von DAWs macht auch TobyB]
> Aber das hier ist krasses Zeug.
Auf jeden Fall, da ist schon was dran. Hier geht es halt darum, einen kommandozeilenorientierten Prozess (für das Notationsvideo aus Teil 1) so weit wie möglich auch durch eine DAW zu unterstützen. Daher kommen die Import-/Export-Funktionen und die VSTs, die die Kommandozeileneffekte nachbilden, damit man interaktiv herumprobieren kann.
> Mich würde interessieren ob man in deinem Ansatz auch Interaktion
> mit Sensoren und Aktoren erzeugen könnte?
Also in dem Kommandozeilenansatz ist das nicht vorgesehen, der geht ja von einem (statischen) Arrangement mit statischer Konfigurationsinformation aus, aus dem vollautomatisiert ein Notationsvideo erzeugt wird.
In einer DAW sieht das anders aus. Jetzt kenne ich die Skriptierbarkeit von Logic zuwenig, aber zumindest über ein VST-/AU-Plugin sollte man Aktoren und Sensoren anbinden können; da weiß ich aber nicht, ob es so etwas gibt.
Was aber auf jeden Fall geht ist, dass man für die Sensoren und Aktoren per Computer – z.B. auch einem separaten Raspi – MIDI-Ströme für Sensoren erzeugt oder solche für die Aktoren konsumiert, die dann in der DAW verarbeitet/generiert werden. Damit kann die umgehen und mit MIDI-2 sollte deren Auflösung gut genug sein.
Oder habe ich Deine Frage falsch verstanden?
Gruß
Fredi
@Fredi Hallo Fredi,
schön von Dir zu lesen :-) Du hast mich schon richtig gelesen. :-) Ich hab mit einem RasPi und einem Fuss-Taster eine MTC realisiert. Einmal tippen, Stopp. Zweimal tippen, Punch In ab Cycle Start. Dreimal tippen, an den Anfang. So hab ich die Hände frei zum spielen.
Wenn ich jetzt deinen Ansatz weiterspinne lande ich bei Interaktion. Ich hab noch keine sinnvolle Lösung hierfür gefunden. Logic und Mainstage haben zwar eine Skriptsprache. Ich bin dann aber auf die Plattform und den Funktionsumfang begrenzt.
Ich muss den Gedanken mal weiterentwickeln, vielleicht wird da ein Artikel draus.
Sers Tob
@TobyB Sowas hatte ich mir auch überlegt, aber aus Erfahrung weiß ich, dass man am Ende mit Rechner, Gehäuse, Schalter etc. auch einiges ausgeben muss. Ich hab dann einen Harley Benton MP100 gekauft, mit dem ich meine DAW (Qtractor) steuere.
@bluebell Ich hatte halt die Teile dafür rumliegen und eh ich sie weg werfe, bastel ich halt ;-) Wenn ich jetzt die Kosten gegenrechne, bin ich immer noch günstiger als ein Harley Benton MP100. Allerdings unflexibler. Der Taster kann nur eine Funktion. Aber ich plane schon eine Erweiterung, siehe unten.
@TobyB Hallo TobyB,
Du schreibst:
> [Ablaufsteuerung über MTC ist gut möglich
> per Raspi]
> So hab ich die Hände frei zum spielen.
Ja, so ähnlich hatte ich mir das vorgestellt. Ein Raspi könnte auch einen kleinen Touchscreen haben, dann kann man auch darüber etwas steuern.
> Wenn ich jetzt deinen Ansatz weiterspinne lande
> ich bei Interaktion. Ich hab noch keine sinnvolle
> Lösung hierfür gefunden.
> Logic und Mainstage haben zwar eine
> Skriptsprache. Ich bin dann aber auf die Plattform
> und den Funktionsumfang begrenzt.
Das geht jetzt sehr stark in die interaktive Performancesteuerung. Du kannst dann einen Vers oder einen Chorus nach Bedarf wiederholen oder den Ablauf komplett umsteuern. Das entfällt bei mir: der Ablauf und das Tempo eines Songs ist eingefroren, ich wähle nur die Reihenfolge der Songs am Tablet aus.
Dass Du dann sehr stark auf die Plattform eingeschränkt bist, leuchtet ein. Aber so etwas sollte beispielsweise für automatisierte Veranstaltungen schon existieren; auf MacOS scheint da ja MainStage durchaus der Platzhirsch zu sein. Du brauchst halt ein Verteilprogramm für MIDI-Ströme auf diverse Abonnenten, die auf diese MIDI-Sequenzen reagieren.
> Ich muss den Gedanken mal weiterentwickeln,
> vielleicht wird da ein Artikel draus.
Das wäre bestimmt interessant!
Gruß
Fredi
@Fredi Hallo Fredi,
ich hab gestern kurz mit den Jungs von Blokas gesprochen. Die wiesen mich auf Patchbox OS hin. Welches auf einem Raspi läuft. Hier gibts die Pakete ORAC, MODEP und PureData. Wenn ich z.B. mit Sensoren interaktiv arbeiten möchte brauch ich noch passende Sensoren und ein Arduino. letztzer kommuniziert als tty mit Raspi und kommuniziert dann via Python. Muss ich weiterdenken. Ich hab sowas ähnliches für die Logistik gebaut, ein Wagen der automatisch hinter einem herfährt und wenn er voll ist, fährt der zum Packplatz und schickt seinen leeren Kollegen zurück. Arduino wertet dabei 3 Sensoren aus und sagt dem Raspi, was los ist. Der Raspi kommuniziert wiederrum nun mit seinen Kollegen. Fertig.
–
Ich hab tatsächlich meinen Bastel Blokas MIDIHUB in einen Raspi Berrybase Touch verbaut. In der finalen Version steuere ich mit Roland FS6 die Presets und das Display zeigt dann die Nummer des Presets an. Da Raspi und die Blokas MIDIHUB Software modular aufgebaut sind, kann man das super erweitern.
@TobyB Hallo TobyB,
nett, ich kannte Blokas und PiSound überhaupt nicht.
Man könnte sich durchaus vorstellen den LTBVC-Ansatz auf so eine Plattform zu bringen. Damit könnten die Notenseiten statt über ein Video per Webserver angezeigt werden (auch verschiedene Noten für unterschiedliche Stimmen sind da kein prinzipielles Problem, da die Datenmenge überschaubar ist) und der Sound wird on-the-fly aus den Stems zusammengemischt.
Danke für den Tipp, darüber werde ich nachdenken!
Gruß
Fredi