Lohnenswertes Upgrade mit hoher Stabilität & optimierter GUI

Alles schön jetzt :laughing:

zu 2.
Na, es geht ja nicht regulär um alle 64 Bit, es geht um Wackelkandidaten, welche Cubase zum Absturz bringen könnten. Hier beugt halt die Plugin Sentinel vor und erkennt im voraus, um welche Plugins es sich da handelt.
Das soll sehr gut funktionieren.

“Verbraucherzentrale”… man, wie bist du denn drauf? :unamused: Heute ist weltweiter Release, es gibt sicher einen Riesenansturm auf Lizenzen, was Server auch mal ziemlich in die Knie zwingen kann !

Die Aktivierungscodes werden doch direkt beim Kauf im Asknet Shop angezeigt. Die Lizenzserver sind etwas überlastet. Bei mir hat’s erst nach dem 5. Versuch (Reparieren-Funktion im elcc) geklappt.

Immer locker bleiben! :unamused:

Ich nicht.
Kann keinen der beiden Punkte bestätigen.
Das anfängliche ‘Chaos’ (erst recht am ersten Tag) ist ja wohl auch eher normal. Wer das umgehen will, sollte sich vielleicht etwas in Geduld üben - und freundlich den Steinberg bzw. asknet support kontaktieren.
Könnte helfen :wink:

Hier wird Unsinn erzählt.

Warum sollen die Kunden das Problem von überlasteten Servern ausbaden. Das hat nichts mit Chaos zu tun, sondern ist eher ein Zeichen für schlechte Planung, die dann auch noch turnusmäßig wiederholt.

Mir wurde auch kein Aktivierungscode im Shop angezeigt - ich warte immer noch auf die E-Mail.

Aus den FAQ: “Haben Sie Software als Download in unserem Online-Shop gekauft, erhalten Sie Ihren Aktivierungscode per E-Mail.”

Zu “Wackelkandidaten”: Wie jetzt? Wacklige 64bit oder was?

Nein, bleibe nicht locker!

Aktivierungscode ist da… ich halte jetzt die Klappe und freu’ mich :stuck_out_tongue:

Dann hasst du nicht richtig hin geguckt, stand direkt unter der Downloadversion.

Kommt schon noch.

Ja, fehlerhaft programmierte 64 Bit Plugins soll es auch geben. :astonished:


Dein Problem! :unamused:

bei mir hat der eLicencer 5 Anläufe gebraucht, take it easy
und wie gesagt, die Lizenznummer wird als erstes direkt beim Kauf angezeigt

ich habe es als grace period update erhalten und das ging sehr flott

Oder, dass ne Menge Drittanbieter ihre Plugins einfach nich sauber programmieren, obwohl sie viel Geld dafür verlangen. Die Funktion versteh ich eher als ne Warnung, bzw. Garantie, wie Cubase einwandfrei funktionieren SOLL. Abwarten… Ne Sandbox für Plugins wäre mir allemal lieber, aber es geht in die richtige Richtung.

Vielleicht für Steinberg interessant: Bei der ersten Initialisierung kommt es teilweise zu Timeouts - wenn man dann auf “Abbrechen” klickt, landet das VST offensichtlich auf der Blacklist. Interessanterweise bei Arturia Analog Lab… Software, die von Steinberg selbst gefeatured wird.

Na ja… lässt sich ja alles reaktivieren.

Oder auch nicht :frowning:

iZotopes “Break Tweaker” und “Stutter Edit” lassen sich als 64bit Version nicht reaktivieren - man möge doch den Hersteller kontaktieren. Auf der anderen Seite ist es mir gelungen ein 32bit VST zu reaktivieren… irgendwie paradox.

Hier sollte Steinberg sein Blacklist-Konzept in Gänze noch einmal überdenken… besser respektive “sicherer” wird damit offensichtlich nichts.

Verwendest Du die VST2 oder VST3 Versionen?

Die VST3 Versionen funktionieren nicht richtig (Frechheit sowas überhaupt zu releasen. mM):
"At this time VST3 automation is not supported in iZotope products.

If you are experiencing issues automating your VST3 iZotope software, please use the VST2 (Windows) or Audio-Unit (Mac) version of your plug-ins instead."
https://www.izotope.com/en/support/knowledge-base/Automation-Support.html

Bin deshalb iZotope mäßig nur auf VST2 unterwegs, nach der ernüchternden Erkenntnis, dass die VST3 nicht richtig funktionieren (automationen werden beim export ignoriert), und ich dann mühsam auf die betroffenen cpr’s auf VST2 izotope umrüsten musste (welche eine andere Plugin ID als die VST3 iZotopen haben).

LG

@Loop Breaker

Vielen Dank für den Hinweis… werde ich erst heute Abend checken können und das Ergebnis dann gerne zurückmelden.

@rheinlandhippie: Du bist auf Windows, oder? iZotope installiert dlls in den VST Ordner die keine validen Plugins sind. Diese werden vom Plugin Sentinel aussortiert. Deine iZotope Plugins sollten aber alle verfügbar sein in Cubase. Bitte check das mal…

Okay, noch ein guter Hinweis… vielen Dank dafür :wink:

Tatsächlich wird kein eigener iZotope-Ordner in Cubase angelegt. Mir war nur nicht klar, dass die unsortierten Einzelplugins direkt als “nicht valide” einzustufen sind. Meines Erachtens sollte das Steinberg einmal überdenken.

Fragt sich, wer wann was mal überdenken muss…
Vielleicht bequemt sich izotope ja auch in den nächsten Wochen, fällige Updates zu produzieren…

…irgendwie kommt es mir hier im Forum immer mehr so vor wie bei “Bauer sucht DAW”… :wink:

…Das Blacklist Konzept scheint zu funktionieren. Ich will gar nicht wissen wie schlampig einige PlugIns programmiert sind und dadurch auch als Problem erkannt werden. Wenn überhaupt ist das ein “Izotope Problem”, keins von Steinberg.

Im KVR-Forum gab es mal eine ausführliche Diskussion dazu, ich versuche mal laienhaft wiederzugeben was ich verstanden hab (und das muss keinewswegs alles stimmen). VST3-Plugins zwingen dich, die Steuerung und die Signalverarbeitung des Plugins zu separieren, so dass beide in unterschiedlichen Prozessen oder im witzigsten Fall auf völlig unterschiedlichen Systemen ausgeführt werden könnten. Man kann sich das Leben auch einfach machen, und diese Funktionalität mehr oder weniger “kurzschließen”, dann ist sie außen vor und VST3 benimmt sich was diesen Punkt angeht in etwa wie VST 2.4 (so machen es wohl die meisten Entwickler). Auch in VST 2.4 konnte man das schon machen, musste aber nicht.

Die Idee ist an und für sich super, aber es macht die Kommunikation der einzelnen Teile eines Plugins recht aufwändig. Wenn du mit der Maus einen Parameter auf der Oberfläche eines VST3-Plugins veränderst, dann weiß die Signalverarbeitung davon zunächst mal nichts. Zeitversetzt erfährt sie auf einem definierten Weg von der Änderung, aber du weißt nicht wann, da der Host die Info weitergibt, und der macht das je nach Puffergröße, Programmierung usw. halt wenn die Zeit dafür gekommen ist, also asynchron. Unter 2.4 konnte die Steuerung eine Änderung direkt an die Signalverarbeitung weitergeben, das ist unter VST3 verboten.

VST3 kann deutlich mehr als VST2.4, aber es ist auch in jeder Hinsicht anspruchsvoller. Und man kann ein VST2.4-Plugin in vielen Fällen auch nicht mal so eben nach VST3 konvertieren, sondern je nachdem wie es programmiert wurde ist u. U. eine komplette Neukonzeption fällig. Während sich Host und Plugin bei VST2.4 hinsichtlich von rund 10 Punkten austauschen, was der eine und der andere so kann, damit sie sich verstehen, sind das bei VST3 um ein vielfaches mehr geworden. Das hat Vorteile für uns User (z. B. brauchte man unter VST2.4 immer zwei Plugins für Stereo- und 5.1, unter VST3 kann das ein und dasselbe PlugIn). Es hat aber auch Nachteile, da sich der Programmierer um ein Vielfaches von möglichen Kombinationen kümmern muss. So kommt es dann, dass ein PlugIn im einen Host super funktioniert, im anderen aber so gar nicht mag.

“Schlampig programmiert” wird hier wie dort, oder auch nicht. Programmieren ist ein Handwerk, und so wie zwei Fliesenleger dieselbe Fläche in unterschiedlicher Qualität abliefern, so werden das auch zwei Programmierer tun. VST2.4-Plugins sind vermutlich etwas weniger komplex zu erstellen und verstehen, und da der Standard seit 10 Jahren nicht verändert wurde auch einfacher ‘stabil’ abzuliefern. VST3 ist ein wachsender Standard, wird mit jeder zweiten neuen Cubase-Version ein wenig angepasst/erweitert, und Steinberg hat die Hoheit über diese Änderungen. Viele Entwickler haben darauf auch ganz einfach wenig Lust und bleiben deshalb fein bei VST2.4, selbst wenn damit nicht alles geht, was mit VST3 möglich ist (z. B. Note Expression).

Merci, Timo,
für diese Erläuterungen zu den VST-Standards!
Wie immer, wenn ein Hersteller die Kontrolle bzw. “Hoheit” über einen Standard hat, kann es dann natürlich manchmal bei den diversen Anbietern (von plugins) dauern, bis diese sich anpassen können - gerade auch nach major updates. Denke, das wird gerne ausgeblendet, und auch ich bin offensichtlich nicht frei von dieser Ungeduld… Eigentlich verdient dein Post ein eigenes Thema!

Nur mal so Nebenbei: Den “Programmierer”, wie er hier immer wieder gerne beschimpft oder vergöttert wird, gibt es so schon lange nicht mehr. Aber finde es immer wieder amüsant, wie einige ihren Ärger mit einer Software auf eine Person (Programmierer) reduzieren.

Software wird entwickelt. Dazu sind unterschiedliche Disziplinen und Rollen erforderlich (Requirements-Management, Requirements-Engineering, GUI-Designer, Architekt, Codierer, Tester usw. um nur ein paar aufzuzählen). Den Codierer könnte man als heutigen “Programmierer” benennen. Dieser hat aber in der Regel nur noch ganz kleinen Einfluss auf die Anwendung, sondern codiert die definierten und spezifizierten Anforderungen und Algorythmen nach Vorgabe.

Softwareentwicklung hat sich massiv weiterentwickelt. Da sitzt in den allermeisten Fällen kein Programmierer der das alles zu verantworten hat. Das sind SW-Projekte mit teilweise fast unzähligen Disziplinen und Rollen. Schaut euch einfach mal in Cubase die “Mitwirkenden” an.

Wenn also die Software “scheisse” ist, dann ist das eher dem Hersteller zuzuschreiben als einem “Programmierer” im klassischen Sinne.