Unter Linux mit Pipewire arbeiten ist der feuchte Traum aller MusikerInnen, die am Computer arbeiten.
Kurz: Mit Pipewire können Audio, Midi und Video unabhängig der Software direkt im System mit virtuellen Kabeln miteinander verknüpft werden. Eine Quelle kann direkt mit theoretisch unendlichen Zielen verbunden werden. Einfach durch das Ziehen eines Kabels von der Quelle zu allen Zielen.
Aktuell wird als Patchbay die Software Helvum empfohlen. Helvum ist stabil und funktioniert. Allerdings ohne speicher- und wieder abrufbare Verkabelungszustände (Recall).
Also wenn Hand angelegt werden muss, um bestimmte Verbindungen herzustellen, ist das einfach machbar, aber spätestens nach einem Reboot muss das wieder gemacht werden. Oder aber auch, wenn Programme gestartet und beendet werden, werden notwendige "Standardverbindungen" mit Kabelstrippen gezogen, die aber unter Umständen den eigenen Bedürfnissen nicht entsprechen. Dann muss wieder Hand angelegt werden.
qpwgraph ist eine Software Patchbay auf Basis von QT6 und QJackCTL, mit dem ein Verkabelungszustand abgespeichert und wieder geladen werden kann.
Wenn die perfekte Verkabelung gezogen wurde, kann das abgespeichert, geladen UND dann aktiviert werden. Im Menü Patchbay gibt es diese 3 Optionen. Zuerst war ich etwas irritiert, dass ich eine geladene Verkabelung aktivieren muss. Allerdings ist das eine tolle Idee, so kann wenn es schnell gehen soll schon im Vorfeld eine Konfiguration geladen und dann auf den Punkt aktiviert werden.
Es gibt noch den Punkt "Exclusive" , der dafür sorgt dass neue Verbindungen verhindert bzw zurückgenommen werden und nur die eingestellte und geladene Verkabelung beibehalten wird.
Schaut euch die qpwgraph an. Für mich persönlich ist das eine unwahrscheinlich wichtige Bereicherung.
qpwgraph kann ganz einfach als Flatpak installiert werden. Getestet unter Kubuntu 22.04, installiert über Discover.
Das Surge Team, das den herausragenden Software Synthesizer SurgeXT heraus gibt kümmert sich seit einiger Zeit um ein weiteres Projekt von @kurasu/Claes Johanson, ebenfalls der Gründer des Surge Synthesizers: Shortcircuit.
Auf der Shortciruit Entwicklerseite ist leider nicht viel zu lesen, um was es sich handelt. Dafür aber auf einem alten KVR Beitrag ist eine längere und informative Beschreibung mit den Spezifikationen (am Ende des Artikels) zu lesen .
Kurz gesagt ist es ein Softwaresampler, dessen Fokus auf einem schnellen Workflow, der hauptsächlichen Nutzung als Instrument und der Integration etlicher Soundformate.
So wie es zu lesen ist, nimmt die Entwicklung langsam Fahrt auf und die ersten Alpha-Versionen können getestet werden. Das Entwicklerteam entfernt gerade betriebssystemabhänigen Code, um ihn mit plattformübergreifendem Code zu ersetzen.
Desweiteren soll zusaätzlich eine sogenannte headless Variante verfügbar sein. Also dass der Sampler ohne eine grafische Oberfläche (GUI) nutzbar ist. Das eröffnet viele neue Möglichkeiten den Sampler für headless (z.B. Raspi), embedded Systeme oder gar integriert in Controllern zu nutzen.
Auch wird der Quellcode umgeschrieben, damit das Entwicklungsframwork JUCE als Backend genutzt werden kann. Dadurch dürfen wir auf moderne Plugin Formate wie CLAP oder VST3 und weitere hoffen.
Die sogenannten Nightly Builds gibt es für Linux / Windows / Mac auf dieser Seite.
Und hier nun wie versprochen die sehr interessanten Spezifikationen, der ursprünglichen Version
User interface:
Streamlined user interface for fast editing at the sample-zone level.
Fast editing of multiple zones.
"In context"-sample preview.
Extensive drag & drop support (onto the keyrange-view or the list-view).
Sample/Instrument import:
RIFF wave-files (.wav) (8/16/24/32-bit & 32-bit float, mono/stereo at any sample rate).
AKAI S5000/S6000/Z4/Z8 .akp banks (partial).
NI battery kits (partial).
Soundfont 2.00 (partial).
Propellerheads Recycle 1 & 2.
Sampler engine:
High-quality sinc interpolation.
Oversampling used when needed to prevent aliasing.
Double-precision float math (64-bit) used where it matters (IIR-filters).
Single-precision float math (32-bit) used elsewhere.
Supports any sample-rate.
Max polyphony per instance: 256 voices.
Multiple outputs (max 16 mono AND 8 stereo-pairs per instance).
Supported sample-playback modes:
Forward / Forward loop / Forward loop with crossfading
Microgate (does glitch/loop style effects when the gate is open).
Ring modulation.
Phase modulation (equivalent to FM).
Frequency shifting.
Pulse oscillator.
Pulse oscillator (with sync).
Sawtooth oscillator (with 1-16 voices in unison)
Sinus oscillator.
3 step LFOs / voice. Doubles as 32-step step-sequencer and wavetable LFO
2 AHDSR envelopes / voice.
Powerful modulation system with the ability to modulate itself. Destinations include envelope-times, loop-points in addition to traditional destinations
Seit einigen Jahren ist CLAP (CLever Audio Plug-in API), ursprünglich von Alexandre Bique gestartet, nun in der Entwicklung und am 15.06.2022 gab es dann die gemeinsame große Ankündigung des neuen Plugin Formates CLAP von Bitwig und und uHe .
CLAP Logo
Ein wenig Technisches
CLAP ist die logische und notwendige Nachfolge der bekannten Formate AU (Audio Unit von Apple macOS) und VST bzw VST3 (Virtual Studio Techonology von Steinberg ). AU und VST/3 sind altgediente Plugin Formate, die weit verbreitet (je nach Betriebssystem und DAW ) sind. Technisch zu ihrer Zeit ausreichend, sind sie dennoch in die Jahre gekommen und es war schon lange notwendig, dass weitere Schritte unternommen werden, um auf den Stand der aktuellen Technik zu kommen.
Das bedeutet, dass unter der Haube eine Menge gemacht werden musste, um die Entwicklung von Plugins zu modernisieren. In aller Kürze ist eine Multi-CPU und Multi-Threading Architektur, bessere Integration in alle DAWs mit transparenteren Zugriffsmöglichkeiten von DAW auf Plugin und eine Menge für die Entwicklung sehr wichtiger Grundlagen wie z.B. Multiplattform (Windows, macOS, Linux, embedded), Metadatenverarbeitung, proprietäre Extensions z.B. wenn Firmen (noch) nicht standardisierte Erweiterungen einbringen wollen z.B. Surround oder Ambisonic , das JUCE CLAP Extension Project, das die Erstellung eines CLAP Plugins für die verschiedenen Betriebssysteme integriert und vieles mehr.
Für die Endanwender sind viele der "unter der Haube" Features zwar auf den ersten Blick nicht so sehr interessant oder shiny, außer vielleicht das Multithreading Feature, aber sie haben einen enormen Einfluss auf die Verfügbarkeit, die Benutzung und zukünftigen Features der Plugins. Stichworte sind hier Midi 2.0 oder MPE.
Lizenzierung - MIT OpenSource Lizenzierung
Und eine extrem wichtige Komponente für eine rechtliche Absicherung bei der Entwicklung von Plugins ist, dass CLAP mit einer Opensource Lizenz, nämlich der MIT Lizenz versehen ist. Das bedeutet, dass alle Plugins entwickeln können, ohne dass jemand es verbieten oder einschränken kann. Gerade für Firmen bzw Gewerbetreibende ist das eine existentielle Absicherung.
Auszug aus der Wikipedia zur MIT Lizenz
Die MIT-Lizenz, auch X-Lizenz oder X11-Lizenz genannt, ist eine aus dem Massachusetts Institute of Technology stammende freizügige Open-Source-Lizenz. Sie erlaubt die Wiederverwendung der unter ihr stehenden Software sowohl für Software, deren Quelltext frei verwendbar ist (Open Source), als auch für Software, deren Quelltext nicht frei verwendbar ist (Closed Source).
Für Steinbergs VST2/3 und Apples AU sind in den Lizenzrechten entsprechende Paragraphen enthalten, die dazu führen können, dass die Herausgeber der Formate LizenznehmerInnen verbieten können Produkte zu entwickeln. Bei VST2 und VST3 gelten dann auch noch unterschiedliche Lizenzen.
Die Benutzer und die Anwendung
Was bedeutet das aber für die EndanwenderInnen?
Sicherheit, dass ein Produkt nicht wegen Entzug einer Lizenz vom Markt verschwindet
Mehr Power und bessere native Unterstützung von modernen Systemen mit Multi-CPU und Multithreading. Eventuell auch (meine persönliche Spekulation) GPU und hier auch Multi-GPU und Multithreading.
Moderne und transparentere Integration von Plugins in DAWs, was zum Beispiel die Automationen und Modulationen destruktiv und non-Destruktiv betrifft
Voice Stacking für alle Plugins. Also z.B die einfache Duplizierung (oder auch mehr Instanzen) eines Plugins, bei der für die verschiedenen Instanzen des Plugins Parameter unterschiedlich eingestellt werden können. Z.B. unterschiedliche Filter CutOffs/Resonanzen, Detuning, Modulatioin usw. Ein klassiches und weit bekanntes Voice Stacking dass in vielen Synth Plugins schon "eingebaut" ist, ist das Unison mit Detuning. Beispiele wie das in Bitwig funktioniert
Schneller Zugriff (Laden) auf die Daten eines Plugins. So können z.B. die Metadaten aus einem Plugin gelesen werden, ohne dass das Plugin zuerst geladen werden muss. Einfaches Beispiel wäre, dass Presets in der DAW durchsucht werden können, ohne dass das Plugin geladen werden muss.
Das alleine sind schon massive Features von CLAP, die das Handling mit den Plugins unglaublich vereinfachen, verbessern und sicherlich kommen da noch vermutlich eine Menge mehr Features auf uns zu.
Ein neuer Standard und wer macht mit?
Standard ist ein sehr wichtiges Thema. Und wenn sich eine Industrie auf einen Standard einigen kann, dann ist das wie Geburtstag, Ostern und Weihnachten auf einmal. Denn alles was von einem Standard abweicht bedeutet für EndanwenderInnen Probleme und Mehrkosten. Nur als kleines Beispiel das Firewire, USB 1/2/3/c/Thunderbold / Lightning Chaos. Und hier kommen dann noch die diversen unterschiedlichen internen Kabelspezifikationen dazu. Kabel ist nicht gleich Kabel, was die Features angeht, auch wenn die Anschlüsse gleich aussehen. Oder HDMI .... oder oder oder.
Daher ist es auch sehr erfreulich die Liste von Firmen zu sehen, die CLAP für sich in Betracht ziehen und das auch zur Zeit testen. Oder sogar schon integrieren oder gar integriert haben. Hier ein kleiner Auszug von Firmen/Projekten mit Nennung von bekannten Produkten, die offiziell genau das tun:
Epic Games mit der Unreal Engine ist besonders zu nennen, da das ein Schwergewicht im Milliarden schweren Gaming Markt ist. Das ist natürlich gerade auch für Entwickler sehr interessant.
Fazit
Das Plugin Format ist aus technologischen und rechtlichen Gründen eine notwendige und längst überfällige Weiterentwicklung der veralteten AU und VST2 / VST3 Formate. Natürlich gibt es auch gerade aus dem OpenSource Umfeld weitere Pluginformate wie z.B. LV2 https://de.wikipedia.org/wiki/LV2 und Artverwandte Formate, die allerdings nie die notwendige Unterstützung aus der Industrie bekommen haben. Mit der MIT Lizenzierung von CLAP wäre es gut möglich, dass die Vorteile der anderen OpenSource Formate mit in das CLAP Format einfließen und wir als Endanwender vielleicht das Glück haben eine Konzentration auf ein freies Format ohne ideologische Grabenkämpfe zu sehen.
Seit einiger Zeit habe ich angefangen meine Tutorials nun auch in Englisch herauszubringen. Auch die alten Tutorials werden so nach und nach auf englisch erscheinen. Die Videos sind mit einer Fahne Englisch/Deutsch und auch im Titel entsprechend gekennzeichnet.
Wenn ihr die Videos gut findet und den Kanal supporten wollt, dann Liked und schreibt mir Kommentare unter die Videos auf YouTube. Das hilft sehr.
Hier ein Auszug, welche Tutorials in der letzten Zeit dazu gekommen sind.
Aktuell gibt es Bestrebungen bei Audio Plugins die Grafikkarte, also die GPU mit in die Berechnungen einzubeziehen. Und kaum wurde das ausgesprochen, kommen von allen Seiten die "Jahhaaaaaa abers ... geht ja nicht" um die Ecke.
Das Hauptargument lautet meist "Du kannst ja den Filter nicht vor dem Oszillator berechnen". Provokativ würde ich sagen "noch nicht", aber das ist ein ganz anderes Thema.
Warum diese Gegenargumentdiskussion komplett irreführend und in weiten Bereichen einfach nur falsch ist, beweisen uns schon die Betriebssysteme unserer Computer, die "Multitaskingfähig" sind. Also subjektiv Aufgaben "gleichzeitig/parallel" abarbeiten. Nimmt man dann auch noch CPUs, die aus mehreren Kernen bestehen und die sich dann noch auf der Hardware virtuell aufteilen können, dann wird aus teilweise subjektiv parallel = objektiv parallel. Weil wenn es die Aufgabe zulässt, dass an 2 Dingen gleichzeitig gearbeitet werden kann und man 2 unabhängige "Arbeiter" zur Verfügung hat, dann können diese beiden Aufgaben auch tatsächlich gleichzeitig/parallel abgearbeitet werden.
Einfache Rechnung: Wenn 2 Kartoffeln geschält werden müssen, sind diese doppelt so schnell geschält, wenn es 2 Personen machen, statt nur einer Person.
Wenn ausgehend von diesem Beispiel natürlich nur ein Kartoffelschälwerkzeug zur Verfügung steht, dann sind natürlich auch 2 Personen nicht schneller. Nur vielleicht insgesamt ausgeruhter. Was auch wieder ein Vorteil sein kann. Aber eines nach dem anderen.
Nehmen wir mal als Beispiel die Auto Produktion (mit ein paar Fantasiezahlen)
Ein Auto besteht aus 10.000 Teilen. Auf der Zusammenbaustrasse werden diese nacheinander, sagen wir von einer einzigen Person zusammengebaut. Zeitvorgabe 1 Woche. Das ist ein klassischer serieller (nacheinander) Prozess. Stellt man dort 2 Personen hin, geht der Prozess vielleicht nicht unbedingt doppelt so schnell, aber auf jeden Fall schneller und die Personen sind nach einer Woche auch nicht so ausgepowert. Die Anzahl der Personen zu erhöhen macht bis zu einem bestimmten Maß Sinn, was den Zusammenbau in einer gewissen Zeit verkürzt (Performance). Irgendwann schafft man dann mit dieser Konstellation ein Auto pro Tag. Mehr Performance.
Der nächste Schritt wäre, diese Zusammenbaustrasse zu duplizieren. Also mit 2 Straßen und der doppelten Menge an Personen bei gleicher Voraussetzung doppelt so viele Autos am Tag zu produzieren.
So die ganz einfache Betrachtung. Bei der aber komplett nicht berücksichtigt wurde, wie denn die Einzelteile, die zu einem Auto zusammengebaut werden überhaupt selbst zusammengebaut werden. Das machen normalerweise die Zulieferer. Würden die Zulieferer das nicht machen, müssten die Personen auf den Zusammenbaustrassen (ja den Begriff habe ich extra aus diesem Grund so gewählt), die Einzelteile selbst herstellen.
Also statt dass einfach eine Tür eingebaut wird, muss diese erst gefertigt werden. Im Extremfall müssen dafür erst die Rohstoffe gefunden, gehoben, veredelt und verarbeitbar gemacht werden. Danach in die entsprechende Form Metall für die Blechhülle, Plastik für die Innenverschalung, Mechanik für die Griffe, das Schloss uswusf. Also so eine Tür könnte sicherlich aus 1000 einzelnen gefertigten Teilen bestehen, die für sich sagen wir mal aus 20 Rohstoffen hergestellt werden, die in verschiedenen Ländern ... uswusf .. ich denke das Prinzip ist klar geworden.
Zusammengefasst: Die Parallelität eines Prozesse besteht nicht aus den Prozessen, die nicht parallelisiert werden können, sondern aus den Prozessen die parallelisiert werden können. Das ist die Aufgabe der Entwickler, zu schauen, was parallelisiert werden kann und wo Parallelisierung keinen Sinn macht. Wo kann man Prozesse auf verschiedene Hardware (Prozessoren) auslagern, welches Auslagern macht wegen der "Bürokratie" (Aufwand, z.B. keine Zeitersparnis) keinen Sinn und wo macht das unter Umständen sogar noch mehr Sinn.
Ganz speziell bei der Betrachtung CPU versus GPU. Audiobearbeitung nutzt extrem viel FFT und FFTS. Grafikkarten, also GPUs haben z.B. optimierte "Schaltkreise" die FFT Operationen extrem schnell und "kostengünstig" (energiesparend) ausführen. Auch wenn eine Grafikkarte mit einem höheren Stromverbrauch angegeben ist, wird sie mit großer Wahrscheinlichkeit bei dieser Operation weniger Strom verbrauchen, als es eine CPU tun würde.
Dass der Stromverbrauch dann ansteigt, könnte eine Folge davon sein, dass die Nutzer dann auch mehr Performance einfordern können/wollen.
Diese wirklich sehr krude Diskussion in vielen Foren ist meines Erachtens eine Zeitverschwendung, weil es absolut auf das Prozessmanagements (Algorithmus) ankommt, das in dem entsprechenden Audio Plugin eingesetzt wird.
Auf meinem Alter Ego hoergen Blog habe ich eine etwas technische Anleitung geschrieben, wie man Windows Plugins unter Linux mit YaBridge installieren kann. Ich betreibe einige Windows Plugins in Linux und Bitwig,die sehr zuverlässig funktionieren.
falkTX von KX.Studio hat das Plugin Ildaeil releaset. Ein VST Plugin für Linux, Windows, und Mac in dem man LV2 Plugins laden und in jeder DAW ausführen kann.
Der Originaltext (automatisch übersetzt)
Ildaeil ist ein Mini-Plugin-Host, der wie ein Plugin funktioniert und die Wiederverwendung von Plugin-Formaten im Verhältnis eins zu eins ermöglicht. Die Idee ist, es als Plugin in Ihrer DAW zu laden und dann das andere "echte" Plugin in Ildaeil. So kann zum Beispiel ein VST3-Host LV2-Plugins laden.
Für die technisch Interessierten: Es handelt sich im Grunde um eine Kombination aus Carla, DPF und DPF-Widgets. Es gibt einen kleinen eigenen Code, der das Zeichnen der Plugin-Liste, die allgemeine GUI und den Ausgleich der eingebetteten GUIs regelt, aber alles andere wird von diesen anderen Projekten erledigt. Nichts, was Ildaeil macht, ist etwas Besonderes, was Carla nicht auch kann, aber wenn man Carla benutzt, muss man immer mit einem zusätzlichen Fenster umgehen. Wenn man z.B. ein einzelnes LV2-Plugin auf einem nicht-LV2-unterstützten Host laden will, wird das ziemlich mühsam. Mit ein wenig Glue-Code, um Carla, DPF und eine kleine GUI zu verbinden, wird dieses Projekt möglich.
In dieser Folge erkläre ich dir den TAL-Filter-2, der leider durch OBS gestört wird, aber das Wichtigste kann ich zeigen und erzählen. Das VST gibt es für Linux, Windows und Macos.
Klangwerk - Blog von Odo Sendaidokai aus Berlin rund um Musikproduktion
Wir informieren euch kostenlos über interessante Konzepte, Tools, Artikel und Tuitorials
Schwerpunkte sind Opensource, Offene Formate, Wissensvermittlung, Erklärungen und interessante Projekte. Die Informationen werden von hoergen aka Odo Sendaidokai zusammengetragen. Und hier findet ihr meine Tutorials und Musik - Warum mache ich das -
