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.