VST2 vs VST3

Weil das Thema im Cubase-Forum noch einmal hochgepoppt ist, möchte ich die gerne nochmal hier die Diskussion spiegeln.
Ausserdem hab ich keinen Bock,

-- mich von eingen der Fanboys dort flamen zu lassen, nur wenn man andeutet, die Developer bei Steinberg haben nicht immer die Qualifikation, die man erwarten könnte....
-- anschliessend dort zensiert zu werden (nur "genehme" Kritik bleibt im Thread, andere wird in die Laberthreads verschoben)

deshalb hier und nicht im Cubase-Forum

zunächst einmal die Basics:

VST3 wurde mit Cubase 4 eingeführt. Es bietet folgende Verbesserungen:
  • Improved Performance
    Managing large plug-in sets and multiple virtual instruments on typical studio computer systems can often be difficult because of CPU performance limits. VST3 helps to improve overall performance by applying processing to plug-ins only when audio signals are present on their respective inputs. Instead of always processing input signals, VST3 plug-ins can apply their processing economically and only when it is needed.
  • Multiple Dynamic I/Os
    VST3 plug-ins are no longer limited to a fixed number of inputs and outputs. Their I/O configuration can dynamically adapt to the channel configuration they’re inserted in, meaning that any VST3 plug-in can be surround-capable with true multi-channel processing. For example, all the new VST3 plug-ins in Nuendo 4 can work in stereo-mode when inserted into a stereo channel, but switch to 6 channels when inserted into a 5.1 channel. Each audio channel is processed independently. Interaction between channels depends on the type and design of the plug-in. In addition to their flexible audio bussing capabilities, VST3 plug-ins may also offer a dedicated event bus. Typically, this is a MIDI input for control/modulation but these busses are no longer restricted to MIDI standard only. Future plug-ins may replace the common MIDI interface with alternative methods of control.
  • Activating/Deactivating Busses
    A typical issue with current virtual instruments is their audio output bussing system and how they’re connected to the mixer after loading. Especially virtual samplers with multiple outputs often occupy more mixer channels than need. The VST3 interface offers the possibility to deactivate unused busses after loading and even reactivate those when needed. This cleans up the mixer and further helps to reduce CPU load.
  • Resizable Edit Windows
    VST3 introduces a new approach to plug-in GUIs though window resizing, allowing for extremely flexible use of valuable screen space.
  • Sample-accurate automation
    VST3 also features vastly improved parameter automation with sample accuracy and support for ‘ramped’ automation data, allowing completely accurate and rapid parameter automation changes.
  • Logical Parameter Organization
    The plug-in parameters are displayed in a tree structure. Parameters are grouped into sections which represent the structure of the plug-in. Parameters like “Cutoff” and “Resonance” could be grouped into a section called “Filter”. This makes searching for a certain parameters easier e.g. on an automation track. This also allows assigning a group of parameters to a specific MIDI Channel input and audio output bus.
  • Optional VST3 / SKI combination :stop:
    As a direct result of the modular interface design of VST3, the Steinberg Kernel Interface (SKI) can be combined with VST3 plug-ins. SKI is an additional SDK that allows extremely close integration of a plug-in with a Steinberg host application, and allows functions to be carried out almost from within the application. This extends to the ability to create tracks, copy, cut, paste or process events in the Steinberg host application. SKI is provided to selected industry partners upon request.
  • VSTXML for Remote Controllers
    Remote controllers for audio and MIDI software applications have become increasingly popular. With VSTXML, VST3 offers far more flexible control of VST plug-ins by remote controllers. Using the knobs and faders on the control surface, parameters can be recorded, renamed and edited in many ways. Parameters that cannot be edited can be routed for display purposes to the control surface, for example to show Gain Reduction on compressor.
  • UTF16 for localized parameter naming
    In VST3, all strings that can be displayed to the user are in Unicode (UTF16) format. Usage of this universal character base allows the host application to display characters in localized languages.
  • No MIDI restriction for parameter value transfers
    VST3 has a dedicated interface for event handling that carries a much wider range of functionality than standard MIDI events would be able to provide. This opens up a big range of opportunities for musical use cases with very high potential for innovative product design. For example with VST3 some controller events (e.g. pitch) can be referred to a note event (using a note unique ID). This offers the possibility to e.g. modulate only a single note which itself is part of a chord.
  • Audio Inputs for VST Instruments
    The VST3 interface expands VST instruments by adding the ability to create audio input busses. As a result, audio data can be routed to an VST3 instrument. A synthesizer which has a built-in e.g. vocoder effect is able to process audio data coming in from other sources as well.
  • Multiple MIDI inputs/outputs
    Unlike with VST 2.x,, a VST3 plug-in can have more than only one MIDI input or one MIDI output at the same time.
  • 64 Bit processing
    VST3 plug-in are generally able to process audio data in 64 Bit.

Die versprochene Revolution blieb jedoch aus.
Eine Suche im KVR nach Hosts, die VST3 unterstützen ergab 14 Resultate, für VST2 254.

Auf der anderen Seite hat VST3 aber auch massive Nachteile:

  • Installation/Verwaltung

    Ein VST3 Plugin kann nicht mehr wie ein VST2 per Drag & Drop in einen beliebigen Ordner installiert werden. VST3 Plugins müssen in vorgegebenen Verzeichnissen (Unter Windows auf C:\blah\blah ) installiert werden. DAWS müssen
    Plugin-Manager implementieren, damit man seine Plugins dann wiederfindet. Für die VST3-Plugins müssen jetzt zusätzlich Setup-Programme implementiert werden.
    Bei VST2 reichte eine Ordnerstruktur. Cubase hat extra ein Feature implementiert, damit die Ordnerstruktur nicht mehr ausgewertet wurde.
    Einer der Gründe, warum sich VST gegenüber DirectX Plugins durchsetzte, war die einfache Installation ohne Registry-Gefuddel. Mit VST3 ist dieser Vorteil verloren gegangen.
  • Performance

    VST3 entzieht einen Plugin die CPU, wenn kein Audio/Midi anliegt. Bessere VST2 Plugins haben das schon immer von sich aus gemacht. Ich habe aber nicht den Eindruck, dass die Plugins wenn sie aktiv sind, weniger CPU brauchen.
    Bouncen und Freezen war schon immer Bestandteil des Workflows, auch Auto-Freeze hätte in den DAWs denselben Effekt gehabt.

Bleibt m.E. nur ein Vorteil: Sidechaining ohne proprietäre Erweiterungen

  • Sidechaining ohne proprietäre Erweiterungen

    Auch wenn ich der Meinung bin, dass hierfür ein neuer Standard nicht notwendig gewesen wäre, so ist dies ein wertvolles Feature. Bisher mussten alle Instrumente oder Effekte, die Audio prozessierten, Vocoder, Kompressoren etc..., ein zusätzliches Carrier-Plugin mitliefern, dass den Sidechain-Input oder den Carrier-Input in das VST einsteuerte, das braucht man heute nicht mehr.
FAZIT

Es bleibt der Eindruch, dass Schteinberg etliche Features, die einfach in Cubase zu implementieren gewesen wären, in die VST-API ausgelagert haben, und einige Cubase-Bugs damit auch wegdelegiert haben. (Fuck U Conman). Ein Standard ist VST3 nicht geworden, und die Verbesserungen wiegen die Nachteile insbesondere in der Verwaltung / Organisation nicht auf. Eine kompatible VST 2.5 Spezifikation wäre sinnvoller gewesen.

Nachwort: Verpasste Chancen

Anstelle der VST3/SKI Integration wäre eine Erweiterung sinnvoll gewesen, die es Plugins erlaubt, auf standardisierte Weise die Rechenpower von Grafikkarten (CUDA) oder dedizierten DSPs zuzugreifen.


Mink
 
zu dem Nachwort möchte ich noch ergänzen:
Steinberg hätte ruhig die Pluginschnittstelle vst3 ähnlich implementieren können wie die Propellerheads das jetzt mit RackExtension gemacht haben. Das wäre ein echter Fortschritt gewesen.

So bliebe das ganze auch in Zukunft abwärtskompatibel und man könnte immer seine alten songs öffnen und sie würden genau so klingen. Bei cubase
ist es leider so, dass es leider nicht mal mit sich selbst richtig abwärtskompatibel ist. Versucht mal ein SX1 oder 2 oder 3 file in cubase 6 zu öffnen und weiterzubearbeiten. Saurer Essig... :doof:
 
hat schon was. Die Begeisterung über VST3 hielt sich ja auch in Grenzen, also ich kenne niemand, der extra dafür lange Wege gegangen ist. Für grössere Produktionen mit mehr als 50 Spuren und entsprechend vielen Plugins lohnt es sich natürlich schon, und für mich war der Umgang mit den Kontakt-Kanälen ein Segen. Und solange man auch VST2-Plugins benutzen kann, finde ich die ganze Sache eigentlich sehr erfreulich.
 
Das Problem war, dass Schteinberg den VST-2 Support sofort reduziert hat (FXB FXP Export) , wobei ch immer noch der Meinung war, das war kein Feature sondern schlichte Unfähigkeit....
Bei mehr als 30 Spuren hab ich immer gefreezed, gerade wenn man so Dickschiffe wie AMP-Simulationen nutzt...

Mink
 
ah ja stimmt, das mit den Presets gab einen grossen Aufschrei damals. Fand ich auch ein bisschen doof, aber irgendwie störte es dann doch nicht, da ich mit zahlreichen MIDI-Controllern arbeite. Ist sowieso gut, die Pluginparameter zu kennen. Wenn ein Anfänger nur Presets kennt und von den einzelnen Parametern keinen Schimmer hat, ist das ein Nachteil.

Für mich ist die DAW nicht das Herzstück des Studios, oftmals wird die "Last" von Effekten auf Hardware und auf andere Rechner ausgelagert und auch analog gemischt. Brauche nie mehr als 30 Spuren.
 
Die Vorteile überwiegen bei VST3, obwohl auch da noch vieles fehlt, um ein komplettes elektronisches Studio abzubilden. Da ist Reason tatsächlich einen Schritt voraus.

Aber ansonsten scheint eine Anpassung an VST3 eben mit Aufwand verbunden, und bis jetzt haben erst gerade ca. 30% der Plugin-Anbieter ihre x64 Migration hinter sich. Diese x64 Migrationen haben Jahre Programmier-Leistung gebunden und auch daher ist die Einführung von VST3 schleppend verlaufen.

Arturia hat nun einige Instrumente nach VST3 erweitert, aber noch nicht alle... Kontakt wäre auch wichtig für mich, für viele...

Steinberg soll doch mit dem nächsten Cubase gleich auch VST4 bringen. Man soll nicht warten. Forwärtsgehen.
 
uuund :hallo: noch.
Bednekte, dass jeder neue "Standard" auch viele Entwickler in Arbeit stüren lässt, ähnlich ie ein neues OS oder eine neue Architektur, die allerdings für Coder auch übers OS läuft, nee APIS ändern viel und schob muss man seinen Synthesizer neu kaufen, wenn man Pech hat als Kunde. Das ist schon ein gewisser Druck.

Hersteller eines "Standards" sind natürlich selbst im Vorteil, da sie diese selbst am besten anpassen und nuen können.

Das der Vorteil natürlich in besserer Performance und so weiter verbessert werden kann ist ebenfalls klar.
 
MarkyGoldstein schrieb:
Steinberg soll doch mit dem nächsten Cubase gleich auch VST4 bringen. Man soll nicht warten. Forwärtsgehen.

Was lassen die dann weg?

CUBASE ist bei mir
* wegen der reduzierten VST2-Unterstützung (Investitionsschutz)
* wegen den hart kodierten Pfaden (wir sind im 21. Jahrhundert, schon mal was von portabler Installation gehört ?)
* wegen den vielen Baustellen, die angefangen, aber nie beendet wurden
* wegen der nicht nur unzeitgemässen, sondern auch nach den Spezifikationen des letzten Jahrtausends (MDI-Style Guide von Microsoft in diversen Programming-Guides) fehlerhaft implementierten GUI
nur noch auf Bewährung auf der Maschine

wenn die nächste Version nicht grundlegende Verbesserungen im Core bringt, fliegts vom Rechner

Moogulator schrieb:
Das der Vorteil natürlich in besserer Performance und so weiter verbessert werden kann ist ebenfalls klar.

Als wenn jemals etwas bei Cubase schneller geworden ist, dann haben Bugfixes Verbesserungen gebracht, aber das gilt nicht. Cubase wird schneller langsamer als die Hardware schneller....

Mink

PS: ich wette um 70 Rappen (alternativ ein Kaltgetränk), das das nächste Killerfeature bei Cubase ein Sampler ist.
 
Ich investiere schon schon seit Geburt von VST in VST und nichts stresst mich mehr als wenn ich sehe, dass das Ding stehen bleibt und die Foundation noch nicht mal reif ist, und dann meine Plugins auf unreifer Foundation sich weiterentwickeln müssen. Es gibt doch noch so viele Dinge, die sich grundlegend verbessern müssen, um all das abzubilden, was man mit Strom anstellen kann (CV Gate, Modulationen, Routing, Patterns, etc.). Im Ernst, seit Karl Steinberg in Pension gegangen ist, ist VST auf der Stufe seines Rock-Studios stehen geblieben :). Reason gibt mittlerweile den Takt in Sachen Innovation vor - leider allerdings ein sehr verschlossenes System..
 
Hi Marky

Ich denke, Du hast irgendwie recht. Einige Exotenfeatures die nur für Cubendo Nutzen bringen, wurden ergänzt, andere Dinge verschlimmbessert. Wenn man hier von Standard redet, so ist das fehlende Zauberwort " offener " . Der Vst-Standard ist eben nicht offen, sondern ein herstellerspezifischer , proprietärer. Das Ergebnis ist, wie Du beklagst, unzureichendes Requirements-Engineering.

Steinberg führt sich hier auf wie Microsoft zu deren schlimmsten Zeiten. Aber, genauso wie Microsoft hat lernen müssen, wird Steinberg das auch...

To make a long story short sowohl die VST als auch die ASIO Spezifikationen sollten an ein Standardisierungskomitee übergeben werden, so wie viele andere echte Standards, sei es SQL, Java , PDF etc.

Dies verlangsamt zwar den Entwicklungsprozess, stellt aber eine
 
Ja, etwas ähnliches wie der Java Community Process wäre gut. Da bin ich 100% einverstanden. Steinberg sollte aus der Vergangenheit lernen versuchen - die Welt ändert sich.
 
Die Gefahr ist, dass Steinberg durch die Kombination von Arroganz (Helga) Unterfinanzierung und persönliche Inkompetenz (musicullum) beides vor die Wand setzt.

Als ich den thread gestartet habe, war die Katastrophe namens cubase 7 Public commercial Beta noch nicht draussen, und die Strategie von Microsoft, mittelfristig midi sterben zu lassen und Plugins in Metro nicht zu unterstützen , mir noch nicht so bewusst.
 
Nachtrag:

Cubase hat die bewährungsauflagen nicht erfüllt und ist geflogen
Die 70 Rappen hab ich verloren, nichtmal das hamse hinbekommen.
 
Ich suche für mich hier zu hause auch eine Alternative zu Cubase. Im Studio haben wir Logic, klar, aber der Dongle sprich Apple ist mir für mal eben was zu Hause machen, zu teuer. Sonst wüßte ich keine Alternative. Mit Reaper bin ich nicht zurecht gekommen, Ableton ist eine ganz andere Geschichte und harmoniert imho nicht gut mit einem Hybridstudio, dh. Hardware/VSTIs , zusammen. Und sonst ... ? :dunno:
 
Ich habe zu reaper gewechselt. Deshalb kann ich da schlecht was sagen, die Einstiegs Hürde ist halt gross, aber da ich das schon lange mache, kannte ich mich da schon aus.

Vielleicht ist sonar oder Studio One ne Alternative .... Teuer zwar aber nicht wirklich unbrauchbar....

Da es hier um die aussterbende Gattung Vst geht, vielleicht wäre ein sauberer Schnitt mit reason auch ein weg.

Oder Zähne zusammenbeissen und reaper ne zweite Chance geben ...
 
War schon ein wenig Ironie

Aber auch ein Bezug auf folgende Diskussion im Windows dev Forum Zischen einem User und einem zuständigen bei ms
----------------
Here are the answers to your questions:
Q. So the bottom line is that "Metro" apps are so isolated that it won't be possible to share VST plugins, or any sort of shared objects?
A. You are correct. The current architecture of Windows strore apps is such that you cannot install a VST or VSTi and share the component between 3rd party applications. However you can ship them for use in your own app.
Q. This also means that a Metro host (e.g. Cubase) is not possible then?
A. It is totally possible. Cubase could partner with a device manufacturer to bundle their Windows store app as a device app for the MIDI device. Cubase could then bundle their own VSTs or VSTis and load them into their app. What can't be done is to share the VSTs, VSTis or MIDI device HW with any other 3rd party apps.
Q. I sure hope you guys come up with something that will overcome this...
A. As stated perviously I have made recommendations to the architecture team to allow for shared plug-ins in future versions of the OS. As an advocate of the development community I have taken up the challenge of convincing the architects that a shared plug-in feature is both necessary and feasible. As always there are no guarantees but rest assured there are those of us here at Microsoft that feel strongly that we need to make sure musicians continue to be welcome on Windows.
Thanks,
James
Windows Media SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

-----------------

Dies zeigt zumindest das mindset, wo microsoft mit Metro hin will. Natürlich soll es weiterhin vsts geben, aber nicht übergreifend und nur über den AppStore . Und Metro ist die Zukunft von Windows, so verstehe ich microsoft.

Das gepaart mit der Tendenz vieler daw Hersteller, zugekaufte Plugins als Innovationen ihrer eigenen daw zu verkaufen, oder proprietäre pseudostandards (reason) zu forcieren, macht mir sorgen.
 
Wie ist der Stand 2016 mit VST 3?

Viele Plugins bieten sowohl VST2 als auch VST3 an.. Installiert Ihr beide oder nur VST 2 oder VST3?

NI unterstützt z.B in Ihren Hosts der Maschine und Komplete keine VST3 Plugins... Dies hat sicherlich seinen Grund oder?

Bin gespannt, danke um Meinungen :)
 
monophonK schrieb:
Wie ist der Stand 2016 mit VST 3?

Viele Plugins bieten sowohl VST2 als auch VST3 an.. Installiert Ihr beide oder nur VST 2 oder VST3?

NI unterstützt z.B in Ihren Hosts der Maschine und Komplete keine VST3 Plugins... Dies hat sicherlich seinen Grund oder?

Bin gespannt, danke um Meinungen :)

Habe bei NI angefragt ob Sie zukünftig mit VST3 planen:
"Die Unterstützung von VST3 Plug-Ins in Maschine 2 und Komplete Kontrol ist derzeit nicht geplant"
 
Ich installiere teilweise beide Versionen um mit älteren Projekten kompatibel zu bleiben. Außer natürlich bei neueren Plugins, die es ja früher :opa: nicht gab.
 
Zurück
Oben