Vst2 wird eingestellt

  • Ersteller BaraMGB
  • Erstellt am
...

ich brauche rückwärtskompatibilität bis zum erbrechen. ich habe da auch herzlich wenig toleranz für irgendwelche sperenzchen, die mir da steine in den weg legen, und zeit, um meine projekte "mal kurz zu rendern" habe ich schon gleich niemals.
...
6. über diese lasse ich dann einmal jbridge laufen und zack, da sind se wieder.

Beim ersten konnte ich noch folgen.
Aber das mit der JBridge it wie Viagra-Rechtfertigung für VST. ;)

Wenn die JBridge immer funktioniert, warum ist sie dann nicht einfach bei Steinberg mit eigebaut?!
 
Beim ersten konnte ich noch folgen.
Aber das mit der JBridge it wie Viagra-Rechtfertigung für VST. ;)

Wenn die JBridge immer funktioniert, warum ist sie dann nicht einfach bei Steinberg mit eigebaut?!
Schöne Polemik, aber halt ohne jede praxisrelevanz ;-)
Ein Unterschied ist zwischen nem "original" und JBridge plugin ist im Alltag nicht bemerkbar. Auch nicht bei den zahlreichen 32bit Schätzchen, die ich seit Jahren (teils aus purer Gewohnheit) weiter verwende.

Kannst du von mir aus "viagra" nennen. Ich nenne es "ich benutze meine Plugins".
 
in kurz: man sollte nicht kaputtschlagen was nicht stört
Ich frag mich auch, was die davon haben. Warum nicht die Bridge für 32Bit Plugins in der DAW lassen? Warum nicht den VST2 Support? Stört doch eigentlich niemanden und sie blieben abwärtskompatibel. Der User könnte entscheiden welches Format
er bevorzugt und Hersteller die kein VST3 anbieten, bleiben bei den VST3 Fans eben außen vor. Wirklich schwer nachzuvollziehen, warum man die User und Hersteller so verärgern muss.
 
  • Danke
Reaktionen: CFR
Kannst du von mir aus "viagra" nennen. Ich nenne es "ich benutze meine Plugins".
Ich hab ja gar nichts gegen die Bridge. In Reaper werden auch Sachen wahrscheinlich unter der Haube gebridget. Man fragt sich tatsächlich nur, warum Steinberg das nicht selbst weiterhin anbietet. Ich wette, das ist eine rein gekünstelte Entscheidung.

Aber vielleicht kommen ja Hersteller auf Steinberg zu und sagen: hey, wir haben keinen Bock mehr auf den Support unserer alten Kamellen, schafft das mal ab, dann haben wir ne Ausrede. Jetzt sieht man auch beim Übergang zu Apple Silicon, dass manche ihren alten Ballast abwerfen, mit dem man vielleicht nichts mehr verdient. Ist aber nur Spekulation.

Eigentlich ist ja das ganze Thema vor dem Hintergrund globaler politischer Ereignisse eher nerdiger Firlefanz.
 
Ich frag mich auch, was die davon haben. Warum nicht die Bridge für 32Bit Plugins in der DAW lassen? Warum nicht den VST2 Support? Stört doch eigentlich niemanden und sie blieben abwärtskompatibel. Der User könnte entscheiden welches Format
er bevorzugt und Hersteller die kein VST3 anbieten, bleiben bei den VST3 Fans eben außen vor. Wirklich schwer nachzuvollziehen, warum man die User und Hersteller so verärgern muss.
Aus demselben Grund, aus dem Apple (deren Produkte du ja wahrscheinlich benutzst) bei deinen Rechnern den 5., dann den 4., dann den 3. und dann alle PCI slots abgeschafft hat, dazu das Diskettenlaufwerk, das CD Laufwerk, PPC und demnächst Intel Kompatibilität, Rückwärtskompatibilität seit Catalina, Kopfhörer Anschlüsse beim iPhone, mitgelieferte Netzteile und Fingerabdrucksensoren.

Time moves on und Firmen fokussieren ihre Ressourcen. Und doof für den User ist es nahezu immer. Der Unterschied ist der, dass zahlreiche der massnahme da oben nicht mit einem 10 euro tool und 60 Sekunden mit paar Mausklicks behebbar sind. Beschwert hast du dich wahrscheinlich trotzdem über die ganze Liste nicht so viel wie über den erhöhten umstiegsdruck zu VST3, der noch gar nicht stattgefunden hat.

Aber klar, so hat halt jeder seine Prioritäten 🤔
 
Eigentlich ist ja das ganze Thema vor dem Hintergrund globaler politischer Ereignisse eher nerdiger Firlefanz.
Darauf können wir uns mit einiger Sicherheit einigen 😄

Und klar ist Teil der Massnahme, dass Steinberg da jetzt nach vielen Jahren versucht, da Druck drauf zu tun um das Thema mal langsam abzuschließen.

Obs ihnen gelingt? Kann mir als User egal sein. Und das ist da ehrlich gesagt das einzige, was mich interessiert.

Vielleicht nachher mal wieder den Timeworks 1080L öffnen. Immer noch ein guter, ganz eigen klingender Hall.

Mit dem guten vintage sound, den man so nur bei direct x Plugins aus den späten Neunzigern hinbekommt 😎
 
@Nachtschicht

Wie so oft, bin ich komplett deiner Meinung, bis auf einen, nicht ganz unwichtigen Punkt:

Jbridge selbst wird nicht mehr laufen.
Es braucht einen neuen Wrapper. Im Grunde sind viele Plug-Ins, die heute VST3 sind, auch mit einem Wrapper realisiert. Juice ist ein Framework, das viele Entwickler nutzen und das ganz unterschiedliche Plug-In-Formate erzeugen kann, darunter auch VST3. Das ist dann eigentliche auch eine Art Wrapper, weil der eigentliche Code in vielen Fällen immer noch auf VST2 basiert. Viele VST3-Plug-Ins sind überhaupt nur so entstanden.

Nur kann ein Wrapper - egal ob das jetzt die Entwicklungsumgebung quasi miterledigt oder ein neues JbrideVST3 ist - die Limitierungen der Schnittstelle nicht umgehen. Was bisher in VST3 nicht ging oder nur sehr quirky, das wird der Wrapper auch nicht hinbiegen.

Das wirst du auch als User merken, ganz deutlich bei allem, was mit MIDI zu tun hat. Mal als ein Beispiel unter vielen: EIn Wrapper kann zwar die Übersetzung von der Steinberg MIDI Abstraktion zu "Legacy MIDI Events" für dein Plug-In übernehmen, aber es kann die sequenzielle Reihenfolge der Events nicht wiederherstellen, weil VST3 die gar nicht liefert. Das ist halt doof, wenn dein Plug-In mit Keyswitches und CCs arbeitet. Das wird dann mal funktionieren und mal nicht. Nicht wirklich schön.

Steinberg möchte halt Artikulationen über die VSTExpression-API abgebildet haben und nicht über CCs und Keyswitches. Das kann ein Wrapper auch nicht ändern.

Das betrifft z.B. User, die NI VSTis mit NI Controllern einsetzen. Das basiert ja alles auf klassischem MIDI. Der NI Controller sendet CCs und das Plug-In erwartet CCs und die auch in der sequentiellen Reihenfolge und einem bestimmten Zeitfenster. Das geht mit VST3 aber nicht. Ich selbst nutze das nicht, aber m.W. lösen die das für die handvoll Plug-Ins, die sie inzwischen auf VST3 portiert haben, so, dass ein solches VST3-Plug-In in eine VST2-Shell geladen wird. Das wird dann aber nicht mehr gehen und da bin ich dann sehr gespannt, wie NI das am Ende löst. Mit einem schnuckeligen Wrapper ist das dann nicht mehr getan.

Lange Rede, kurzer Sinn:
Diesmal wirst du als User nicht ganz ungeschoren davonkommen.
 
Meine Meinung dazu:

Seit dem Erscheinen von Vst3 im Jahre 2008 versucht Steinberg systematisch ihr eigenes Vst2 Format vom Markt zu drängen. Trotz massiver Gegenwehr ist ihnen das bis heute nicht gelungen. Versuche gab es viele. Der letzte Versuch starte im Jahr 2018. Das SDK wurde entfernt. Es gab eine Schonfrist für Hersteller. Sie mussten bis zum 1 Oktober 2018 die Lizenzvereinbarung unterschreiben oder sie durften keine plugins oder Hosts(DAWs) veröffentlichen die vst2 nutzen. Nach dem 1 Oktober 2018 war es keinem Hersteller mehr möglich eine Lizenz für Vst2 zu bekommen. Vst3 wurde open source.

Niemand in der Entwicklerscene versteht warum Steinberg so regide gegen Vst2 vorgeht. Es ist eines der erfolgreichsten Projekte in der Audiogeschichte. Open source Projekte wurden (und werden immer noch) gegängelt, weil sie einen nachgebauten Vst2 Header benutzen um das Format zu unterstützen. Neuen Entwicklern wird es verboten Vst2 zu unterstützen, während alte Entwickler das Format unterstützen dürfen (weil sie noch rechtzeitig die Lizenzvereinbarung unterschrieben haben).

Egal, ich habe mittlerweile meinen Frieden damit gemacht. Man kann es jetzt eh nicht mehr ändern. Aber ich unterstütze diese Firma nicht mehr. Ich hoffe dass es bald ein neues plugin Format gibt, das nicht von steinberg kommt und die hersteller nicht gängelt.
 
@Nachtschicht

Wie so oft, bin ich komplett deiner Meinung, bis auf einen, nicht ganz unwichtigen Punkt:

Jbridge selbst wird nicht mehr laufen.
Es braucht einen neuen Wrapper. Im Grunde sind viele Plug-Ins, die heute VST3 sind, auch mit einem Wrapper realisiert. Juice ist ein Framework, das viele Entwickler nutzen und das ganz unterschiedliche Plug-In-Formate erzeugen kann, darunter auch VST3. Das ist dann eigentliche auch eine Art Wrapper, weil der eigentliche Code in vielen Fällen immer noch auf VST2 basiert. Viele VST3-Plug-Ins sind überhaupt nur so entstanden.

Nur kann ein Wrapper - egal ob das jetzt die Entwicklungsumgebung quasi miterledigt oder ein neues JbrideVST3 ist - die Limitierungen der Schnittstelle nicht umgehen. Was bisher in VST3 nicht ging oder nur sehr quirky, das wird der Wrapper auch nicht hinbiegen.

Das wirst du auch als User merken, ganz deutlich bei allem, was mit MIDI zu tun hat. Mal als ein Beispiel unter vielen: EIn Wrapper kann zwar die Übersetzung von der Steinberg MIDI Abstraktion zu "Legacy MIDI Events" für dein Plug-In übernehmen, aber es kann die sequenzielle Reihenfolge der Events nicht wiederherstellen, weil VST3 die gar nicht liefert. Das ist halt doof, wenn dein Plug-In mit Keyswitches und CCs arbeitet. Das wird dann mal funktionieren und mal nicht. Nicht wirklich schön.

Steinberg möchte halt Artikulationen über die VSTExpression-API abgebildet haben und nicht über CCs und Keyswitches. Das kann ein Wrapper auch nicht ändern.

Das betrifft z.B. User, die NI VSTis mit NI Controllern einsetzen. Das basiert ja alles auf klassischem MIDI. Der NI Controller sendet CCs und das Plug-In erwartet CCs und die auch in der sequentiellen Reihenfolge und einem bestimmten Zeitfenster. Das geht mit VST3 aber nicht. Ich selbst nutze das nicht, aber m.W. lösen die das für die handvoll Plug-Ins, die sie inzwischen auf VST3 portiert haben, so, dass ein solches VST3-Plug-In in eine VST2-Shell geladen wird. Das wird dann aber nicht mehr gehen und da bin ich dann sehr gespannt, wie NI das am Ende löst. Mit einem schnuckeligen Wrapper ist das dann nicht mehr getan.

Lange Rede, kurzer Sinn:
Diesmal wirst du als User nicht ganz ungeschoren davonkommen.
Davon betrifft mich dann tatsächlich nur der eine Punkt, nämlich dass jbridhe selbst geupdatet werden muss. Das tun sie hoffentlich, sonst tuts jemand anderes, aber ich will gerne weiter diesen Entwickler unterstützen.

Gibt's da schon Äußerungen? Sonst müsste man ja glatt mal ne ermutigende Kunden Email schreiben...
 
Das wirst du auch als User merken, ganz deutlich bei allem, was mit MIDI zu tun hat. Mal als ein Beispiel unter vielen: EIn Wrapper kann zwar die Übersetzung von der Steinberg MIDI Abstraktion zu "Legacy MIDI Events" für dein Plug-In übernehmen, aber es kann die sequenzielle Reihenfolge der Events nicht wiederherstellen, weil VST3 die gar nicht liefert. Das ist halt doof, wenn dein Plug-In mit Keyswitches und CCs arbeitet. Das wird dann mal funktionieren und mal nicht. Nicht wirklich schön.

Was heißt das? Daß VST3 nicht mal die Midi Events mit ordentlichen Timestamps versieht und nicht in korrekter Reihenfolge liefert?
Wenn dem so wäre, wäre VST3 der allergrößte Dreck, den die Welt gesehen hat. Dann kann man ITB auf Win Rechner in Zukunft komplett vergessen.
 
Zuletzt bearbeitet:
Was heißt das? Daß VST3 nicht mal die Midi Events mit ordentlichen Timestamps versieht und nicht in korrekter Reihenfolge liefert?
Wenn es so wäre, wäre VST3 der allergrößte Dreck, den die Welt gesehen hat.

Das kann man so nicht sagen. VST3 bietet grundsätzlich sogar sample-genaue Synchronisation, was an sich ja eine gute Sache ist und was mit VST2 so einfach nicht ging. VST3 benutzt aber dafür eine eigene API oder ein Objektmodell (so wie S1 das im ganzen Programm auch macht) und die ist das eigentliche Problem. Es gibt auf KVR reichlich interessante Diskussionen darüber, u.a. mit Markus Krause und Urs Heckmann. Auch ein Entwickler von Ardour ist dabei. Da kannst du das mal in aller Ausführlichkeit aus der Sicht eines Host-Entwicklers und zwei Veteranen der Plug-In-Szene nachlesen.

Mit Timestamps für MIDI-Events kommst du heute sowieso nicht mehr weit, weil MIDI selbst viel zu ungenau ist, um z.B. eine sample-genaue Synchronisation zu ermöglichen.
 
@John_Lennon kannst du den KVR Thread bitte mal verlinken? Ich würde mir das gerne mal durchlesen.
 
Mit Timestamps für MIDI-Events kommst du heute sowieso nicht mehr weit, weil MIDI selbst viel zu ungenau ist, um z.B. eine sample-genaue Synchronisation zu ermöglichen.
Ok, dann ist die Sache doch anders. Aber ein Midi Controller liefert auch nur sporadisch Daten, nicht für jedes Sample. Die Abtastrate der Controllerdaten ist auch deutlich geringer, wohl eher 1 kHz. So kritisch kann das also nicht sein.
 
VST3 benutzt aber dafür eine eigene API oder ein Objektmodell (so wie S1 das im ganzen Programm auch macht) und die ist das eigentliche Problem.
Wobei das in S1 kein Problem darstellt, sondern sogar dazu führt, dass VST2 Plugins über das interne Control-Link-System nicht an die 128 möglichen MIDI-Werten gebunden sind und daher auch eine Sample-genaue Synchronisation möglich ist. Das ermöglicht z.B. eine stufenlose Parameterautomation für virtuelle Instrumentenparts. Presonus hat sich absichtlich dafür entschieden, weil eben der alte Midi Standard gewissen Einschränkungen unterlegen ist.
 
Wobei das in S1 kein Problem darstellt, sondern sogar dazu führt, dass VST2 Plugins über das interne Control-Link-System nicht an die 128 möglichen MIDI-Werten gebunden sind und daher auch eine Sample-genaue Synchronisation möglich ist. Das ermöglicht z.B. eine stufenlose Parameterautomation für virtuelle Instrumentenparts. Presonus hat sich absichtlich dafür entschieden, weil eben der alte Midi Standard gewissen Einschränkungen unterlegen ist.

Ich würde mal so sagen: Man kann sowas auf verschiedene Arten implementieren und S1 macht das offenbar auf die bessere Art. Aber SysEx geht glaube ich nicht, oder?
 
So jetzt sind alle Antworten von den Herstellern da, deren Plugins ich nutze, und bei denen noch kein VST3 vorliegt, dauerte gerade mal max. 24h:
XLN Audio , P&M, Gforce, Relab und 2cAudio (VST3 wohl Ende des Jahres) arbeiten schon an VST3.
Lexicon hat das auf dem Schirm, aber mehr noch nicht.

Fazit für mich:
Alles für mich Relevante wird, wenn es soweit ist zur Verfügung stehen.
Die meisten Hersteller hatten das eh auf dem Schirm.

Mein Eindruck, die hatten das immer weiter nach hinten geschoben, weil es ja noch keinen echten Druck gab.
Jetzt ist der Druck da, und jetzt wird halt dran geschafft.

Ich für meinen Teil muss sagen, wieder weniger was ich zusätzlich installieren muss.
Ich habe keine 32 Bit Plugins mehr, dann werde ich VST2 nicht mehr installieren, nur noch ein Format, was für mich funktionieren soll.
Passt.
 
Zuletzt bearbeitet:
@John_Lennon kannst du den KVR Thread bitte mal verlinken? Ich würde mir das gerne mal durchlesen.

Es sind mehrere und auch ältere Threads. Aber ein guter Start - weil ziemlich aktuell - ist der CLAP-Thread bei U-He:

U-He auf KVR

Um VST3 geht es da aber erst im Verlauf des Threads.

Hier ein Thread explizit zu MIDI in VST3:
MIDI in VST3
 
Ich habe mal den thread hier gefunden :

https://forums.steinberg.net/t/vst3-and-midi-cc-pitfall/201879

Hier wurde es ziemlich gut erklärt. So wie ich das verstanden habe, hat Steinberg im ursprünglichen vst3 die Midi CC Unterstützung rausgenommen, weil sie der Meinung sind, dass ein plugin damit überhaupt nicht umgehen sollte. Es sollte dem Host, also der DAW, obliegen, Midi CC Daten zu verwalten. Nur aufgrund des Drucks der Hersteller, die in ihren plugins weiterhin midi learn als Feature anbieten wollten, hat man das nachträglich wieder rein genommen. Nur muss ein plugin jetzt 16x128 Parameter implementieren (16 Midi channel mal 128 parameter) um das nutzen zu können. Das ist natürlich eine enorme Ressourcenverschwendung und Mega unpraktikabel.
 
Ich frag mich auch, was die davon haben. Warum nicht die Bridge für 32Bit Plugins in der DAW lassen? Warum nicht den VST2 Support? Stört doch eigentlich niemanden und sie blieben abwärtskompatibel. Der User könnte entscheiden welches Format
er bevorzugt und Hersteller die kein VST3 anbieten, bleiben bei den VST3 Fans eben außen vor. Wirklich schwer nachzuvollziehen, warum man die User und Hersteller so verärgern muss.
Laut Aussagen von Steinberg UND PreSonus (Ari) ist das Stress für die DAW. Ich würde auch nie auf die Idee kommen, olles Zeugs, was nicht gewartet wird, zu benutzen. Wir leben im SW-Zeitalter und tickt verdammt schnell. Irgendwann ist Schluß mit altem Zeugs.
 

Ähnliche Themen

solokeyboarder
Antworten
0
Aufrufe
328
solokeyboarder
solokeyboarder
C14 - frag mich
Antworten
0
Aufrufe
364
C14 - frag mich
C14 - frag mich
RECORDING-Redaktion
    • Danke
  • Artikel
Antworten
0
Aufrufe
473
RECORDING-Redaktion
RECORDING-Redaktion

Oft gelesene Themen

Zurück
Oben