Das Problem an VST3 ist neben dem erwähnten Handling von komplexen GUIs mit viel Interaktion, nicht zuletzt MIDI. VST3 abstrahiert MIDI vom Plug-In-Core und verwendet dafür eine
Steinberg-eigene API. Plug-Ins, die darauf angewiesen sind, die rohen MIDI-Daten so zu bekommen, wie der Controller sie liefert, sind nicht mal so eben portierbar, weil sie diese Daten vom Host gar nicht erst bekommen.
Das ist das Problem von Herstellern wie
Toontrack, die zum einen in ihren Plug-Ins eine hochkomplexe GUI haben und zum anderen im Fall von SD3 ja das Frontend für Drum-Controller/E-Drums sind. Gehen tut natürlich am Ende irgendwie alles und wenn es mit einem Haufen von Workarounds ist. Nur dass die dann wieder Fehlerquellen sind oder Ressourcen binden.
Plug-Ins wie die von Soundtoys, die simple GUIs mit oft nicht mal einer Hand voll Knöppe haben, die zudem nicht zeitkritisch bei der Bedienung sind und die auch keine Real-Time-MIDI-Steuerung brauchen, sind da problemlos. Und in dem Fall darf man als User sicher auch berechtigterweise dem Plug-In-Hersteller in den Hintern treten.
Aber Hersteller wie Toontrack oder auch NI, die nicht mit JUICE arbeiten und das vielleicht auch gar nicht können, weil die GUIs dann gar nicht möglich wären, die stehen vor einem massiven Problem. Auch UAD hält nicht an VST2 fest, um User und/oder Steinberg zu ärgern. Das Abstraktionslevel von VST3 macht es schwierig für ein Plug-In, seine GUI mit seinem Core kommunizieren zu lassen, wenn dieser gleichzeitig wiederum mit der Hardware kommunizieren muss.
Bei VST2 war das alles ungeheuer einfach, das ist ein sehr schlankes Format und gibt dem Plug-In alle Möglichkeiten, in seinem einen, monolithischen Prozess alles selbst zu machen, was es braucht. VST3 macht es für Steinberg leichter, Stabilität in den Host zu bekommen. Aber für die Plug-In-Entwickler macht es das Leben massiv schwerer bis fast unmöglich.
Man kann die unterschiedlichen Ansätze ja an zwei Implementierungen von ähnlichen Plug-Ins sehen. Voltage Modular als VST3 Vertreter und das frisch erschienene VCV Rack 2, das es bisher nur als VST2 gibt. Das hat schon seinen Grund, der VCV Entwickler macht das nicht, um User oder Steinberg zu ärgern.
Bis vor fünf Stunden hätte ich CLAP nicht die geringste Chance gegeben, mittlerweile hat sich das geändert. EIne Migration von VST2 zu CLAP soll sehr einfach sein und damit wird das für Entwickler sehr attraktiv.
Eher implementiert Steinberg irgendwann CLAP, als sich in Zukunft nur noch auf VST3 zu beschränken.