Neues Plugin-Format CLAP

  • Ersteller Gel Mitglied 84274
  • Erstellt am
Blöd bei Cubase ist nur, dass VST2 gar nicht mehr anzeigt, wenn VST3 mit installiert wird.
Wenn beide Versionen unterschiedliche IDs haben, werden sie schon in Cubase angezeigt! Und Urs hat das berücksichtigt.
1639743619078.png
 
Wenn beide Versionen unterschiedliche IDs haben, werden sie schon in Cubase angezeigt! Und Urs hat das berücksichtigt.
Ja, bei U-HE ist es wohl so. Ich hab hier viele Plugins, wo das aber nicht der Fall ist.
Meist mache ich Automation auch über die QC in Cubase, aber manchmal ist ein einfaches Midi Learn schneller, gerade wenn der Parameter nicht in der QC ausgewählt ist.
Das Zuweisen über Rechtsklick auf einen QC funktioniert bei manchen Plugins nämlich auch nicht immer zuverlässig. Bei manchen ist die Option einfach nicht vorhanden.
Will sagen, einen richtigen Workflow bekomme ich da nicht hin, da sich die Plugins oftmals unterschiedlich verhalten.

Ich hatte auch einige Zeit die Funktion VST3 aussetzen genutzt. Da war es manchmal so, das Cubase sich verschluckt hat.
Reaper bekommt das z.B. anstandslos auch mit VST2 hin.

Das bringt mich zu der Annahme, dass VST3 für Entwickler schon etwas schwieriger zu händeln ist.
 
Ist grundsätzlich erstmal ein gutes Zeichen, dass irgendjemand endlich mal die Eier in der Hose hat, eine Alternative zum Quasi-Standard VST zu entwickeln. Für mich MUSS so etwas essentielles wie ein Austauschformat von Audio-Plugins quelloffen sein. Seit 25 Jahren hängt die ganze DAW-Welt an VST und AU.

Natürlich steht in den Sternen, ob CLAP jemals in der Lage sein wird, o.g. zu ersetzen, aber von der Idee her ist es erstmal gut.
 
Ich halte mal fest, dass das bisher praktischste Anwendungs Szenario "ich möchte einen eq mit einem komprossor steuern" war und lass das mal so stehen :-D
 
Ich halte mal fest, dass das bisher praktischste Anwendungs Szenario "ich möchte einen eq mit einem komprossor steuern" war und lass das mal so stehen :-D
Was ja prinzipbedingt auch mit VST2 geht, aber manche DAW-Hersteller aufgrund ihrer verbauten Architektur nicht hinbekommen wollen. Sidechain funzt "nur einfach" mit VST3, basta, gehört auch dazu.
 
Ich halte mal fest, dass das bisher praktischste Anwendungs Szenario "ich möchte einen eq mit einem komprossor steuern" war und lass das mal so stehen :-D
Nein, es war nur ein simples Beispiel für Leute die Bitwig nicht kennen und die Idee die dahinter steckt.

Man muss auch nicht für jeden Kram automatisieren oder Plugins laden, vieles lässt sich über die Modulatoren lösen.

Es kommt dem Humanize am ehesten nah. Klingt halt lebendig.
 
Mit der Midi-Steuerung und CC*s gibt es seit ewigen Zeiten Probleme mit VST3.
Urs empfiehlt deshalb bei seinen Plugins auch immer noch VST2 mit zu installieren, wenn man es braucht.
Blöd bei Cubase ist nur, dass VST2 gar nicht mehr anzeigt, wenn VST3 mit installiert wird.

Hier noch das Zitat vom U-HE Support:

Unfortunately, due to limitations in the VST3 standard, some features found in the VST2 versions of our plug-ins are not available in their VST3 versions.


  • We removed the MIDI Learn functions. While the MIDI Learn interface is available in VST3 versions, nothing happens because VST3 does not use raw MIDI data. In order to receive MIDI control changes (CC), the plug-in needs to report hundreds of special parameters to the host, one for each CC per MIDI channel. Until this is directly implemented in VST3 hosts, MIDI Learn is only available in the VST2, AU and AAX versions of our plug-ins.
    Note: Settings assigned in the other plug-in formats will be adopted by the VST3 version. This means you can set up your controllers using the VST2/AU/AAX version, then replace it with the VST3 version afterwards.
  • A single MIDI CC only controls a single plug-in parameter due to limitations of the VST3 standard.
  • Presets with a dot (period) character in their name may not display the name correctly and navigation may jump to first preset in folder.
  • When using Cubase (before 9.5), if the MIDI programs folder is used, the first preset from this folder is loaded on startup.
  • GUI resizing does not work correctly in some hosts.
Es gibt einen ziemlich schlüssigen Beitrag in den Steinberg Foren, der erklärt, dass das Mapping von Midi-CC auf die Parameter, die vom Plugin exponiert werden, Sache der DAW ist. Sprich die DAW bittet dem User die Möglichkeit, z.B. Breath auf Parameter XYZ zu routen. Diese Aufgabenteilung ergibt absolut Sinn und ich frage mich, warum dieses CC-Geschichte aus den GM-Zeiten als ein wichtiges Argument gegen VST 3 gelten soll... Nö. Dass das DSP-Gurus nicht passt, sorry, I don't care. Nö. Selbst Hermann Seibts VST Host kann das, siehe https://www.kvraudio.com/forum/viewtopic.php?t=491180. Ist wohl kein Problem der VST3 Spec, sondern der DAW implementierung.
Die anderen Punkte sind - Bugs in Hosts. Okay, DSP-Guru zu sein qalifiziert also nicht automatisch, sich qualifiziert über Specs aufzuregen.

Die CLAP-Spec ist übrigens nicht neu und ich meine bereits über 4 Jahre alt. Ich hab sie mir auf Github angeschaut. Klar, viel brauchbares dabei, allerdings auch Mist, z.B. Multithreading per "Threadpool": Also die DAW ruft das plugin auf, das plugin ruft dann wieder die DAW auf und sagt "bitte berechne folgendes auf irgendeinem Thread in deinem Threadpool". Diese hin-und-her Indirektion ist hirnrissig. Zweitens Threadpools!? Es gehört zu einer richtigen "Aufgabenteilung", dass die DAW die Kontrolle über den "Weg der Berechnungen" durch die Plugins hat und dieses optimal auf die CPUs verteilt.
Beispiel: Man hat einen Processing-Graph, der mit Per-Unisono-Voive läuft, d.h. das LFO-Plugin im Plugin-Synth wird tatsächlich nicht nur pro Midi-Note, sondern pro Unisonso-Voice gefahren (Beispiel Bitwig)...der EQ nach dem Synth-Plugin wird ebenso per Unisons-Voice gefahren, ebenso wie der Wavesaper.
Es wäre gut, wenn die DAW sagt: "Okay ich habe den Processing Graph analysiert, ich mappe den Mist so auf die CPUs, dass möglichst wenig CPU-Cache-Misses entstehen" (Performance!), oder man macht es wie bei Clap, dass jedes Plugin sagt "Gib mir irgendeinen Thread, ich muss gerade Zeug berechnen", d.h. statt CPU-Caches optimal zu nutzen, dadurch dass die DAW einen optimalem Processing-Graph berechne kann, lässt man Plugins entscheiden, ob sie einen Threadpool nutzen wollen. Threadpool!?

Lange Rede kurzer Sinn: Clap ist mEn nicht wirklich DER revolutinäre nächste Schritt bzgl. Funktionalität. Wenn man natürlich VST aus Gründen hasst, dann schon. Die Entwicklungszeit, die DAW-Entwickler und Plugin-Entwikcler in die Umsetzung dieses Standards versenken, die wird woanders fehlen und die werden wir zahlen müssen.
 
Die CLAP-Spec ist übrigens nicht neu und ich meine bereits über 4 Jahre alt. Ich hab sie mir auf Github angeschaut. Klar, viel brauchbares dabei, allerdings auch Mist, z.B. Multithreading per "Threadpool": Also die DAW ruft das plugin auf, das plugin ruft dann wieder die DAW auf und sagt "bitte berechne folgendes auf irgendeinem Thread in deinem Threadpool". Diese hin-und-her Indirektion ist hirnrissig. Zweitens Threadpools!? Es gehört zu einer richtigen "Aufgabenteilung", dass die DAW die Kontrolle über den "Weg der Berechnungen" durch die Plugins hat und dieses optimal auf die CPUs verteilt.

Urs hat bereits bestätigt dass die steuerung des multithreadings seitens daw einen performance boost von 10%+ (!?) erzeugt. und auch dieses modell ist nicht neu, apple hat das ebenfalls für logic eingeführt wenn ich mich recht erinnere. außerdem ist es kein muss diesen threadpool zu nutzen, sondern optional via extension. hinzukommt dass das format ja immer noch weiterentwickelt wird und bei gutem input auch sowas wie die von dir angesprochene aufgabenverteilung implementieren kann, entweder direkt als teil der spec oder selbst als extension.

Lange Rede kurzer Sinn: Clap ist mEn nicht wirklich DER revolutinäre nächste Schritt bzgl. Funktionalität. Wenn man natürlich VST aus Gründen hasst, dann schon. Die Entwicklungszeit, die DAW-Entwickler und Plugin-Entwikcler in die Umsetzung dieses Standards versenken, die wird woanders fehlen und die werden wir zahlen müssen.

der resonanz der entwickler nach, die sich bereits zu wort gemeldet haben, ist CLAP schnell adaptiert was ja auch wieder als einer der vorteile von CLAP gegenüber z.b. VST3 galt. es gibt selbst erste header für frameworks wie JUCE und adapter die von CLAP zu VST oder AU mappen sollen. die "versenkte" zeit hält sich also schneinbar sehr in grenzen und in einer zeit wo auch nach 13 jahren VST3 noch hinterher hinkt, wären ein paar wochen für CLAP das weitaus kleinere übel.

ich finds jedenfalls weiterhin gut, je mehr ich darüber lese. gerade hinsichtlich: vst2 wird vertrieben und clap könnte diese lücke füllen. gerade neue entwickler die keinen zugriff mehr auf vst2 bekommen und mit dem wesentlich komplexeren vst3 einsteigen müssten, könnten CLAP nutzen und erhielten alles andere automatisch.
 
Zuletzt bearbeitet:
Es gibt einen ziemlich schlüssigen Beitrag in den Steinberg Foren, der erklärt, dass das Mapping von Midi-CC auf die Parameter, die vom Plugin exponiert werden, Sache der DAW ist. Sprich die DAW bittet dem User die Möglichkeit, z.B. Breath auf Parameter XYZ zu routen. Diese Aufgabenteilung ergibt absolut Sinn und ich frage mich, warum dieses CC-Geschichte aus den GM-Zeiten als ein wichtiges Argument gegen VST 3 gelten soll... Nö. Dass das DSP-Gurus nicht passt, sorry, I don't care. Nö. Selbst Hermann Seibts VST Host kann das, siehe https://www.kvraudio.com/forum/viewtopic.php?t=491180. Ist wohl kein Problem der VST3 Spec, sondern der DAW implementierung.
Die anderen Punkte sind - Bugs in Hosts. Okay, DSP-Guru zu sein qalifiziert also nicht automatisch, sich qualifiziert über Specs aufzuregen.
Und was ist mit VST3 MIDI output (Sequenzer-, Audio to MIDI-plugins)?
War mit VST2 kein Problem, im Gegensatz zu VST3.
Ok, irgendwann hat Steinberg dann ja mit LegacyMIDICCOutEvent für CC output nachgelegt, vermutlich aufgrund vieler Klagen, aber MIDI Noten output funktioniert immer noch nicht m.W., und das ist m. Mn. nicht nachvollziehbar.

Ausserdem bist du auf einen m. Mn. wichtigen Punkt von CLAP gar nicht eingegangen, nämlich proprietäre vs. freie Lizenz, dazu schreibt (.z.B). Urs (U-He) auch im KVR thread.
 
Zuletzt bearbeitet:
Ja, bei U-HE ist es wohl so. Ich hab hier viele Plugins, wo das aber nicht der Fall ist.
Meist mache ich Automation auch über die QC in Cubase, aber manchmal ist ein einfaches Midi Learn schneller, gerade wenn der Parameter nicht in der QC ausgewählt ist.
Das Zuweisen über Rechtsklick auf einen QC funktioniert bei manchen Plugins nämlich auch nicht immer zuverlässig. Bei manchen ist die Option einfach nicht vorhanden.
Will sagen, einen richtigen Workflow bekomme ich da nicht hin, da sich die Plugins oftmals unterschiedlich verhalten.

Ich hatte auch einige Zeit die Funktion VST3 aussetzen genutzt. Da war es manchmal so, das Cubase sich verschluckt hat.
Reaper bekommt das z.B. anstandslos auch mit VST2 hin.

Das bringt mich zu der Annahme, dass VST3 für Entwickler schon etwas schwieriger zu händeln ist.

In den Cubase Einstellungen gibt's ein Häkchen VST3 bevorzugen. Wenn du das weg machst werden alle VST2 und alle VST3 angezeigt.
 
Ich finde es gut, das sich technisch Kreative aufmachen und was Neues probieren.

Und wenn es was taugt, werden auch alle einfach mitmachen.
Wenn nicht geht es halt Gassi.

Das Bessere ist des Guten Feind.
Aber jetzt muss das ja erstmal werden.

Meine Gelassenheit ist da grenzenlos :)
 
In den Cubase Einstellungen gibt's ein Häkchen VST3 bevorzugen. Wenn du das weg machst werden alle VST2 und alle VST3 angezeigt.
Wo finde ich denn genau diese Einstellung?
Bei manchen Herstellern werden mir ja beide Versionen angezeigt. Bei manchen nicht, obwohl beide Versionen installiert sind.
 
Gibt noch keine offizielle Verlautbarung (m.W.) aber dem screencapture nach zu urteilen (von schwa, einem der Reaper Entwickler) könnte Reaper wohl CLAP-plugin hosting bekommen.

 
cool wäre es, wenn es einen vst-to-clap converter gäbe
und clap systemübergreifend, also auch unter reaper auf linux laufen würde... :smil451c7211b9e19:
 
cool wäre es, wenn es einen vst-to-clap converter gäbe
Du meinst warscheinlich für die Enduser, oder?
Davon hab ich noch nix gehört, soll aber wohl recht einfach sein für Plugin Entwickler bestehende VST Plugins in's CLAP Format zu konvertieren, hab auch schon von einem CLAP drop-in für's JUCE Framework gelesen.
Und neben Reaper (warscheinlich) ist Bitwig wohl auch schon mit an Board (hab nen Video gesehen wo ein CLAP Plugin in Bitwig läuft).

und clap systemübergreifend, also auch unter reaper auf linux laufen würde... :smil451c7211b9e19:

Naja, wenn CLAP Unterstützung für Reaper kommt bin ich mir ziemlich sicher dass das auch auf der Reaper Linux Version der Fall sein wird (schon zumal Justin wohl Linux Fan ist, sonst gäb's warscheinlich gar kein Linux Reaper).
 
Du meinst warscheinlich für die Enduser, oder?
yepp, dachte eher an den enduser...
Naja, wenn CLAP Unterstützung für Reaper kommt bin ich mir ziemlich sicher dass das auch auf der Reaper Linux Version der Fall sein wird (schon zumal Justin wohl Linux Fan ist, sonst gäb's warscheinlich gar kein Linux Reaper).
na cool wäre ja schon, wenn ein clap auf allen systemen läuft.
bei vst sind die plugs für linux, mac und win ja leider unterschiedlich...
 
na cool wäre ja schon, wenn ein clap auf allen systemen läuft.
bei vst sind die plugs für linux, mac und win ja leider unterschiedlich...

Ach so meinst du, hab ich glaub falsch verstanden.
Ich denke man wird dann immer noch für Win/Mac/Linux kompilierte Plugins für das jeweilige OS brauchen (ausser man nutzt halt sowas wie Wine).
 
Nur zur Info Bitwig 4.3 Beta und Surge XT Nightly sind schon vor den jeweiligen Releases ein gutes Gespann.
Bitwig implementiert CLAP ebenso wie Surge XT Nightly (https://github.com/surge-synthesizer/releases-xt/releases/tag/Nightly)
Surge XT als Clap Versionunterstützt in Bitwig Note Expressions und Bitwigs Per-Voice Modulators!

Weil oben jemand schrieb - "es wird kaum jemand aufspringen": Kommt darauf an, wie viele Leute von VST3 genervt sind. Die ganze OS/Linux-Musiker sind es. Aktuell ist es wohl richtig, dass noch nicht besonders viel angeboten wird. U-He liefert mWn alle Plugins ebenfalls als Clap aus. Und eben Surge XT. Es gibt bereits einen Clap-Erweiterung für das Synth Programmierframework JUCE, einen Adapter, damit man in RUST (neue Programmiersprache, 'leichter als C++) programmieren kann... Mal sehen.
 
Lese da gerade das erste Mal von. Finde ich hochinteressant, zumal die Gängelungen seitens der Plugin-Protokoll-Rechteinhaber (in Ermangelung besserer Worte) ja tatsächlich wohlbekannt sind. Das ist mir persönlich wichtiger als zusätzliche Funktionalität.
Problematisch an diesem neuen Format wird sein, dass vermutlich mindestens 2 Platzhirsche, namentlich Steinberg und Apple, zumindest für Jahre nicht mitziehen werden, da weiterhin die eigene Suppe gekocht werden muss.
 

Oft gelesene Themen

Zurück
Oben