VST2 / VST3

[Rex]

Mal ne generelle Frage:

Laut Steinberg:

"VST3 Features
Verbesserte Performance

Der Einsatz vieler PlugIns und mehrerer virtueller Instrumente auf einem typischen Projektstudio-Computersystem kann oft problematisch sein, weil die Leistungsressourcen schnell ausgeschöpft sind. VST3 hilft dabei, die Gesamtperformance zu verbessern, da nur dann Audiodaten berechnet werden, wenn tatsächlich ein Signal anliegt. VST3 PlugIns verhalten sich daher besonders ökonomisch und verbrauchen nicht unnötig Systemressourcen, wenn gerade auf der entsprechenden Spur kein Audiomaterial abgespielt wird."

Bei S1 erkenne ich keinen Unterschied in der cpu-Leistungsanzeige. Egal ob VST2 oder VST3 plugin-Version im insert liegt oder ob audio-event aktiv.

Verstehe ich da was falsch oder sind die Unterschiede im Grunde nicht mess- bzw. anzeigbar. Oder muss ich in S1 etwas einstellen?

 

[starcorp]

Das ist auf heutigen Rechnern nicht mehr der Rede wert.
Der Grösste Vorteil von Vst3 für die Entwickler liegt glaube ich darin, man die Gui skalierbar programmieren kann und die Plugins Sidchain fähig sind.

Jan

 

[tsching]

Das ist auf heutigen Rechnern nicht mehr der Rede wert.

Und wie es das ist. Ich hatte mal einen Vergleich zwischen der VST2 und VST3-Verison des VSL Instrument Players gemacht, da hat die VST3-Version auf einem relativ aktuellen i7-Prozessor etwa 15% weniger Leistung beansprucht.
Es gibt noch eine ganze Menge weiterer Vorteile von VST3, wie z.B. die automatische Konfiguration der Ein- und Ausgänge (ob mono oder stereo oder Mehrkanal), eine feinere Automationsauflösung, Abschaltbarkeit von Einzelausgängen, natives Sidechain, Audio-Eingänge für Instrumente, multiple MIDI-Ein- und Ausgänge und noch einiges mehr.
Wichtig ist aber auch, das der Host das alles unterstützt.

 

[terrablue]

Das mit der Mehrleistung bei VST3 stimmt schon. VST2 Plugins verbrauchen auch CPU wenn sie gerade inaktiv sind, also wenn z. B. ein VST2-Synth gerade nicht angesteuert wird, verbraucht er CPU. Bei VST3-PlugIns ist das nicht der Fall.

 

[Rex]

Und wie es das ist. Ich hatte mal einen Vergleich zwischen der VST2 und VST3-Verison des VSL Instrument Players gemacht, da hat die VST3-Version auf einem relativ aktuellen i7-Prozessor [color=#ff0000; text-decoration: underline]etwa 15% weniger Leistung[/color] beansprucht.
Es gibt noch eine ganze Menge weiterer Vorteile von VST3, wie z.B. die automatische Konfiguration der Ein- und Ausgänge (ob mono oder stereo oder Mehrkanal), eine feinere Automationsauflösung, Abschaltbarkeit von Einzelausgängen, natives Sidechain, Audio-Eingänge für Instrumente, multiple MIDI-Ein- und Ausgänge und noch einiges mehr.
Wichtig ist aber auch, das der Host das alles unterstützt.

Danke für die klare Aussage.

Dachte, die Performance-Unterschiede wären größer (als ca. 15%).

Bei mir ist mit Studio one als host jedenfalls kein Performanceunterschied anhand der cpu-Leistungsanzeige erkennbar. Egal ob ich die Vst2 oder vst3-Variante eines plugins verwende und ob in der audiospur was läuft oder nicht.

Entweder versteckt sich der Performanceunterschied-Effekt innerhalb des statistischen cpu-Leistungsanzeige-Flackern oder es liegt am host und solche Unterschiede sind hauptsächlich beim vst-Erfinder Cubase implementiert bzw. erkennbar.

 

[starcorp]

Das ist auf heutigen Rechnern nicht mehr der Rede wert.

Wichtig ist aber auch, das der Host das alles unterstützt.

Das hatte ich eigentlich so salopp gemeint.
Entscheident ist Heute, wie verteilt die Daw die Prozesse in einem Mehrkern System. Können Plugins mehere Treads eröffnen und unterstützt das Betriebssytem wiederum eine gleichmässige Verteilung der Lasten auf möglichst viele Kerne.
Bei solchen Brocken wie Vsl oder Kontakt mit Orchester librarys spielt es bestimmt eine Rolle.
Hier noch mal ein Tread der sich mit der Sone Leistungsanzeige befasst hat.
https://recording.de/Community/Forum/sequencer/presonus_studio_one/183052/thread.html

Jan

 

[ach]

Das mit der Mehrleistung bei VST3 stimmt schon. VST2 Plugins verbrauchen auch CPU wenn sie gerade inaktiv sind, also wenn z. B. ein VST2-Synth gerade nicht angesteuert wird, verbraucht er CPU. Bei VST3-PlugIns ist das nicht der Fall.

Falls ich irgendetwas richtig verstanden habe, scheint S1 auf diese Option bei VST3 zu verzichten. Es entsteht also auch Last wenn Synths/FX nicht angesteuert werden. Das hat den Vorteil, dass der Rechner nicht irgendwann völlig in die Knie geht wenn richtig viele Spuren abgespielt werden. Man kann so von vornherein Knackser & Co. vermeiden.

 

[John_Lennon]

Es gibt bei KVR einige Diskussionen von Entwicklern darüber und der generelle Tenor ist eigentlich, dass trotz allen Vorteilen VST3 kein glückliches Design ist. Hauptproblem ist die threadmäßige Trennung von GUI und Audioverarbeitung, die von vielen Entwicklern einfach nicht beherrschbar ist. Woran das nun genau liegt und ob es eher das Problem der Entwickler oder ein grundsätzliches Fehldesign ist, mag ich aus der Ferne nicht beurteilen.

Es ist allerdings auffällig, dass einige Plugin-Hersteller zwar VST3-Versionen anbieten, von dem Einsatz dieser Versionen aber abraten.

Und ich selbst habe Tage damit verbracht herauszufinden, warum sich einige wenige ältere Projekte nicht mehr in Cubase 8.5 öffnen ließen. Am Ende war es die VST3-Version von Satin, die Cubase beim Laden des Projektes abstürzen ließ.

Also ganz so rosarot ist die Sache nicht.

 

[Navar]

Hauptproblem ist die threadmäßige Trennung von GUI und Audioverarbeitung, die von vielen Entwicklern einfach nicht beherrschbar ist. Woran das nun genau liegt und ob es eher das Problem der Entwickler oder ein grundsätzliches Fehldesign ist, mag ich aus der Ferne nicht beurteilen.

Naja, also eigentlich dürfte das keine zu großen Probleme bereiten wenn man weiß was man da macht. Das Problem bei der Entwicklung von Multi Thread basierten Anwendungen ist, dass man, wenn man davon keine Ahnung hat, ziemlich schnell Mist bauen kann, der sich hinterher nur schwer debuggen lässt. Gerade für Quereinsteiger kann das ziemlich tricky werden, wenn man das nicht vernünftig gelernt und verstanden hat.

 

[tsching]

Hauptproblem ist die threadmäßige Trennung von GUI und Audioverarbeitung, die von vielen Entwicklern einfach nicht beherrschbar ist. Woran das nun genau liegt und ob es eher das Problem der Entwickler oder ein grundsätzliches Fehldesign ist, mag ich aus der Ferne nicht beurteilen.

Ich habe auch einige Kontakte zu Plug-In-Entwicklern und oftmals ist es so, dass die Vorgaben von Steinberg für VST-Plug-Ins so "zurechtgebogen" werden, dass man da noch eigene Sachen reinhackt. Das scheint bei VST3 eben nicht mehr so gut zu gehen, weshalb viele sich die zusätzliche Arbeit sparen. Ich finde das schade, weil am Ende de Anwender den schwarzen Peter hat.
Übrigens: Der Entwickler-Support für VST2.4 ist seitens Steinberg bereits Ende 2013 (!) eingestellt worden. Ich denke, dass Cubase nur deshalb noch VST2.4 Plug-Ins unterstützt, weil soviele Hersteller noch nicht umgestellt haben.

 

[Gast92251]

Bei mir ist mit Studio one als host jedenfalls kein Performanceunterschied anhand der cpu-Leistungsanzeige erkennbar. Egal ob ich die Vst2 oder vst3-Variante eines plugins verwende und ob in der audiospur was läuft oder nicht.
.

Heutzutage sind Plugins ressourcenschonend programmiert, sowieso auf Leistung getrimmt, da man so gut es geht auch Echtzeit ermöglichen möchte.

Verwende aber mal ein richtig CPU-hungriges Plugin, dann wirst auch du den Unterschied im "Leerlauf" zwischen VST2 und VST3 bemerken. VST3 schaltet ab wenn kein Audiosignal anliegt, wohingegen VST2 immer die "volle Latte" Leistung zieht.

Zudem macht das auf etwas betagteren Notebooks u.a. schon was aus, hier nutze ich bevorzugt VST3.

.

 

[Gast92251]

... VST-Plug-Ins so "zurechtgebogen" werden, dass man da noch eigene Sachen reinhackt.
Das scheint bei VST3 eben nicht mehr so gut zu gehen, weshalb viele sich die zusätzliche Arbeit sparen. Ich finde das schade, weil am Ende de Anwender den schwarzen Peter hat.
Übrigens: Der Entwickler-Support für VST2.4 ist seitens Steinberg bereits Ende 2013 (!) eingestellt worden. Ich denke, dass Cubase nur deshalb noch VST2.4 Plug-Ins unterstützt, weil soviele Hersteller noch nicht umgestellt haben.

Eigentlich können wir froh sein, dass VST2.x noch von unseren DAWs unterstützt wird:
Denn anders schaut es bei AVID aus, dort wurden mit Einführung des AAX-Formates rigiros alle vorherigen Formate (RTAS, AudioSuite und TDM) gestrichen und wurden über Nacht schlagartig ubennutzbar. Wer das damalige Pro Tools-Update fahren wollte, war somit gezwungen, alle Plugins auf AAX nachzukaufen, Alternativen zu suchen oder auf Updates der Pluginhersteller zu warten. Das waren zusätzliche Kosten, die nicht wenigen PT-Usern einen schlimmen Herzkasper verursachten. (Mir u.a. auch).




.

 

[John_Lennon]

Für VST 2.x habe ich selbst auch mal ein kleines Plugin als Fingerübung entwickelt. Da kann ich noch ein bisschen mitreden, bei VST3 allerdings nicht mehr, das habe ich noch nicht mal gesehen.

Ich kann daher nur wiedergeben, was Urs Heckmann und einige andere Entwickler in den KVR-Threads dazu gepostet haben und das war recht schlüssig. Urs ist nun auch alles andere als ein Anfänger...

Es gibt inzwischen ein "simplified VST3", das Steinberg den Entwicklern, die Probleme mit VST3 haben, ans Herz legt. Das scheint auch grundsätzlich einfacher zu handeln, aber einige Entwickler müssten dann ihre VST3-Plugins noch mal neu machen und dazu fehlt wohl ein bisschen die Lust - so lese ich die Diskussionen auf KVR jedenfalls.

Wer sich mal ein bisschen einlesen will:

http://www.kvraudio.com/forum/viewtopic.php?f=31&t=398532

Gute Übersicht (ein Posting aus diesem Thread):

The problem lies buried deep in the overambitious design of VST3.

One of the intended "phenomenal" changes to VST2 was the strict separation between audio processing and controlling part. They are two independent objects in VST3(.0), and their communication is designed to be done through asynchronous messages sent between them. The messaging is performed by the host. This allows, in the grand scheme of things, niceties like running the processing on one machine and the editor on another.

In practice, with this asynchronous messaging scheme, they introduced an unmanageable nightmare, because anything that is remotely timing-dependent doesn't work reliably any more. Plus, they added a nice little "double-binding" in the SDK. If you look at the VST2 Wrapper, you'll notice that it effectively shortcuts the messaging process. It simply fuses the two components together and introduces a synchronous messaging scheme. This is, as a very nice example, totally different to how Cubase handles things - but relatively consistent with the model, since a VST2 PlugIn can only run on one machine anyway, so there's no need for an elaborate message passing mechanism.

Third part of the puzzle: as a host writer who wants to support VST3, you have to decide on your own scheme how to do it. There's no guidance except for the VST2Wrapper, which deliberately bypasses the problem. Guess what - each VST3-supporting host has its own way to deal with asynchronous message passing. Some of these may even make it impossible to fire a message and wait until the answer has arrived (just imagine they're passed as posted window messages), while others won't work asynchronously at all (my hosts, for example, copy the VST2Wrapper behaviour, since they can't split the processing and editing parts anyway) - if, as a PlugIn writer, you decide to "go by the rules", simply fire a message and return, waiting for the result to come in at a later time, you're screwed as it's already there as soon as the message firing has been completed. You need to be prepared for all these scenarios - and, unfortunately, some of them are mutually exclusive. The only chance to get out of this is to react differently on each host. Out of the frying pan, bang straight into the fire...

tl;dr - asynchronous messaging doesn't work reliably. Getting it to run in Cubase alone is a little nightmare, getting it to run in other hosts as well is a big nightmare.

That's why Steinberg added a simplified model where processing and controlling part are allowed to reside in one object, thereby removing the schizophrenic need for them to talk to each other. Of course, if you already invested a lot of time into creating a PlugIn using the separated model, it means quite a lot of work to switch back to the simplified model. You have my heartfelt sympathies, Urs

 

[Gast92251]

Wie auch immer.
Dann sollte man doch vllt. den harten Schnitt in allen DAWs machen, und ausschliesslich VST3 erlauben.
Wie AVID mit seinem AAX-Format. Hinzukommend wäre es hier denkbar, alle erscheinenden VST3 Plugins von einem unabhängigen Konsortium auf Herz und Nieren prüfen zu lassen, also ganz ähnlich, wie es AVID mit AAX erfolgreich macht - denn das eliminiert Plugin-Konflikte und DAW-Abstürze auf ein Mindestmaß. Die Idee, welche dahinter steckt, macht schon Sinn. Ganz ähnlich wie Apps aus dem Apple-Store, welche vorab ausführlich getestet und freigegeben werden.
Auch ein Statement zu diesem Thema.

Ferner vermisse ich VST3 bei Native Instruments, eine der größten Pluginschmiede, schon lange. Da gibt es dringend Handlungsbedarf, nur meine Meinung dazu.


Von Plugin-Programmierern aus reiner Bequemlichkeit von VST3 abzuraten, diese vielleicht gar nicht anzubieten, das ist der falsche Weg.


AAX ist auch nicht einfach, aber dort klappt es schliesslich auch. Mit Erfolg.


.

 

[starcorp]

Wie auch immer.
Dann sollte man doch vllt. den harten Schnitt in allen DAWs machen, und ausschliesslich VST3 erlauben.

Von Programmierern aus reiner Bequemlichkeit von VST3 abzuraten, diese vielleicht gar nicht anzubieten, das ist der falsche Weg.

Au warte, du bist ja streng. Ob das die zillionen Hobbyanwender mitgehen würden?
Die Plugins müssten ja neu Progammiert werden und die Programmierer wollen verständlicherweise bezahlt werden.

Jan

 

[John_Lennon]

Wie auch immer.
Dann sollte man doch vllt. den harten Schnitt in allen DAWs machen, und ausschliesslich VST3 erlauben.

Wenn VST3 wirklich ein Fehldesign ist, wie in dem von mir verlinkten Thread diskutiert wird, dann würde das eine mittlere Katastrophe - für Hersteller wie User. Das kann niemand wirklich wollen.

 

[Gast92251]

@starcorp: natürlich nicht. Reine provokative Äusserung meinerseits.
Habe selber ein paar ältere, seltene aber geniale Plugins, welche in Pre-VST 2.3 oder sogar in 2.2 vorliegen. Diese laufen in Cubase 8.5 jedenfalls. Noch. Und das ist auch gut so.

.

 

[Dodo_I]

Also Effekte gibt es von Drittanbietern inzwischen haufenweise als VST3, Instrumente hingegen kaum.
Möglicherweise sind diese wohl einfacher zu programmieren.

Ansonsten habe ich selten bis keine Abstürze mit meinen VST2-Plugins.
Diese habe ich allerdings von Drittanbietern auch ziemlich reduziert, benutze meist die Immergleichen und mache auch immer jedes Update mit.

Gut, bei Effekten ist es auch einfacher, auf "absturzproblematische" Plugins zu verzichten, wie zuletzt auf die Focusrite Midnight "Suite" ...

 

[intercorni]

Die Cubase internen PlugIns unterstützen diese Performance-Einsparung von VST3. Daher wenn nichts anliegt, wird auch nichts berechnet.