PlugIn Blacklist

@StoneHillStudios: hier ist alles beschrieben: viewtopic.php?f=250&t=107163

ich glaube das gibts auch auf Deutsch zu lesen?

Eine Frage hätte ich trotzdem. Ich sehe bis jetzt trotz diesen Erklärungen keinen Zweck darin Dll’s anzuzeigen oder auch nicht anzuzeigen die nichts mit einem möglichen Plugin zu tun haben.

Dlls die nur wie bei iZotope als Hilfsbibliotheken im gleichen Verzeichnis sind, die sollten einfach ignoriert werden. Weder sollten diese Dlls in der Blacklist erscheinen noch sollten sie sonstwo in Cubase von Interesse sein.
Dlls’ die gerne eine VST sein möchten sollten anhand ihrer Schnittstellenangaben erkannt werden können und damit sollten alle anderen Dlls im Verzeichnis automatisch ignoriert werden können. Es ist für die Benutzer nur verwirrend diese Dateien in der Blacklist anzuzeigen -bringt aber rein gar nichts :wink:

Warum also können und sollen solche Dll’s in der Blacklist erscheinen die offensichtlich gar keine VST-Schnittstelle enthalten ?

Plugin Hersteller anschreiben und nachfragen ob es ein Update gibt.
Wenn sich die Programmierer nicht an die vorgaben der VST SDK haltem, kann keine maximale kompatibilität und stabilität gewährleisten werden.

Ich finde das gut das Steinberg da jetzt knall Hart durchgreift.
Bei Avid wird das mit AAX auch genaus so gemacht.

Diese Frage habe ich auch.
Es könnte sein, dass diese Unterscheidung gar nicht so einfach zu treffen ist.
Beantworten kann dies nur Steinberg.

Diese Frage habe ich auch.
Es könnte sein, dass diese Unterscheidung gar nicht so einfach zu treffen ist.
Beantworten kann dies nur Steinberg.

Auch finde ich richtig, das Steinberg Plugins aus Cubase bannt, die eben nicht korrekt entwickelt wurden.
Da dies die erste Version mit Plugin Sentinel ist, gibt es sicherlich noch Verbesserungsbedarf hinsichtlich der korrekten Plugin-Erkennung.

Das mit der Blacklist ist fast so, wie die Frage “Wer hat Angst vor dem schwarzen Mann” :slight_smile:
Das grundsätzliche Debakel ist einfach diese 32/64 Bit Aktion, die Steinberg hier, in der
Absicht eine Art von Marktbereinigung vornehmen zu wollen, verursacht.
Das jedoch auch “ordentlich” gebridgde 32Bitler durchs Raster fallen hat nichts mit dem
Schreckgespenst namens Sentinel zu tun sondern ganz schnöde mit der Tatsache das hier
ein neuer Bug zu Tage getreten ist. Nur am Rande und völlig leidenschaftslos bemerkt ist
es dem Scan völlig egal ob es sich dabei um Originale oder Cracks handelt.

MEIN Problem war Anfangs, dass ich in Cubase 8.5 noch 32 Bit Versionen von Plugs & VSTi
nutzen konnte, da 8.5 noch die vernüftige Möglichkeit bot, die bridgerei intern vorzunehmen.
Leider ist seit der 9er aber endgültig sense damit. Da ich aber nicht auf meine Schar von
32 Bitlern verzichten will musste ich das also extern via jBridge erledigen lassen.
Die Folge war, dass ich sämtliche 32Bit Plugs/VSTi welche ich bislang intern durch Cubase 8.5
bridgen ließ nun nochmals selektieren und mit jBridge Cubase 9 zur Verfügung stellen musste.

Bei dieser Aktion ist mir ein Fehler unterlaufen und es befanden sich durch meine
Unachsamkeit einige doppelte Plugs/VSTi in jenem Ordner, auf den 8.5 UND 9
gleichzeitig zugreifen. Cubase 9 machte augenblicklich dicht und beförderte sämtliche
jener dppelten Plugins und VSTi in die Blacklist.
Ich habe daraufhin alle gebridgden 32Bitler aus dem zuständigen Ordner heraus gelöscht
und danach einen Ordner namens Bridged 64 angelegt und in diesen Ordner nochmal
aufs Neue ALLE 32Bitler in einen jeweiligen Unterordner gebridged abgelegt.
Auf diesen Ordner greifen nun 8.5 und 9 gleichermaßen zu. Auf die ehemals interne
8.5 bridgerei verzichte ich nun zwar gänzlich ABER: die Blacklist in 9 ist sauber, sprich leer
und alles läuft ohne Probleme.
Sollten einige dll Exoten der 32 Bit Generation das bridgen partout ablehnen, dann
ist dann der Moment des definitiven Abschieds davon gekommen. Zumindest was die
Arbeit unter CB 9 betrifft.

Beste Grüße

Das sehe ich ganz genauso!
Da meine jetzige Blacklist schon ziemlich lang ist, aufgrund irgendwelcher pluginrelevanter Extra-DLLs, die leider teilweise im Pluginordner selbst liegen müssen, graut es mir ein bisschen vor diesem Upgrade, zumal der Sentinel ja leider nicht deaktivierbar ist.
Dort nun die evt. aus Sicherheitsgründen zusätzlich reingeschobenen RICHTIGEN Plugins zu finden, um sie ggf. zu reaktivieren, könnte eine Menge Arbeit machen.

Eine Frage an die glücklichen C9 User:
Entspricht die Blacklist im Plugin Manager 1:1 der im Einstellungsordner, oder wird dort doch evt. was weggespart?

Mein lieber Scholly, wo ist da das Problem?
Ich habe über 800 gescannte plugins (funktionieren Alle inkl. jbridge PLugs), in der Blacklist sind irgendwas mit 30 “Bibliotheken-dll-Plug-Gedöns-Teile”.
Ja, braucht man nicht, bin ich bei Euch, stört mich jetzt aber null.

Die Plugs, die welche sind, sind alle da. Wenn da mal eins in der Blacklist ist, ist doch kein Ding das zu finden :unamused:

Vor allen Dingen deshalb, weil es ja die Pluginhersteller sind, die ihren Müll da hinein kippen. Der Sentinel verhält sich völlig korrekt und standardkonform. Eure Probleme möchte ich haben…

Vor allen Dingen deshalb, weil es ja die Pluginhersteller sind, die ihren Müll da hinein kippen.

Du meinst den Ordner mit den VST2 ?

Bevor man irgendwelchen Herstellern einen Vorwurf über vagabundierende Dll’s machen kann müsste man folgende Fragen beantworten:

  • a) Gibt es gemäss den Steinberg- Spezifikation eine Vorschrift wo Plugins ihre allfällig zusätzlich notwendigen Dll’s abzulegen haben?
    b) Wurde für den VST 2 -Ordner welche Plugins enthalten von Steinberg ein bestimmter Pfad für zusätzliche Dll’s vorgeschrieben?
    c) Lassen sich Plugin Dll’s von Hilfsbibliotheken die im gleichen Verzeichnis sind leicht und automatisiert voneinander trennen?

Und jetzt meine Antworten dazu nach meinem gegenwärtigen Wissensstand:

  • a) Ich sehe keine solche Vorschrift
    b) Ich sehe von Steinberg auch keine Vorschrift welche festlegt wo genau der VST2 Ordner zu liegen hat
    c) Ja, man kann Plugin Dll’s beim laden anhand der Schnittstellendefinition als Plugin erkennen.

Meine Ausführungen dazu:

Wegen c) sehe ich nicht ein warum andere Dlls die keine Plugin sind oder sein möchten als fehlerhaftes Plugin in einer VST2 -Blacklist erscheinen müssen. Denn von Steinberg gibt es keine Vorschrift für die VST2 -Pfade auf der Festplatte und auch nicht eine Vorschrift für relative Pfade zu allfälligen Hilfs-Dll’s eines Plugin.

Windows:
Bei Windows hat Microsoft aber Empfehlungen herausgegeben für die Pfade von Dlls die von Programmen mehrerer Hersteller über eine bekannte öffentlich zugängliche Schnittstelle aufgerufen werden.
Alle solche 64bit Dlls sollten in diesem Pfad und dessen Unterverzeichnissen liegen:
C:\Program Files\Common Files

also sowohl die VST2 als auch die VST3 Plugin sollten auf Windows in diesem Pfad plaziert werden. Seht doch mal bei euch nach was dort alles zu finden ist :wink:

Der Grund ist, das nur Dlls die unter “Common Files” bzw. gemeinsame Dateien abgespeichert sind vom Windows Betriebssystem (auch in Zukunft) angemessen als Plugin behandelt werden. Damit meint Microsoft die Rechteverwaltung, es wird sicher gestellt das es unter diesem Pfad zu keinen Konflikten mit Benutzerrechten bei gemeinsamen Dateien kommen kann. VST -Plugin sind gemeinsame Dateien.

Der von vielen Windows -Nutzern oder Installationsprogrammen gewählte Ort für die VST2 Plugin ist aber C:\Program Files\VST oder \VST2 oder \VSTPlugin und noch weitere Orte -aber nicht alle Plugin sind im dafür vorgesehenen Platz unter Common Files abgelegt.

Zusammengefasst gesagt, es gibt von Steinberg keine Vorschriften wo Hersteller die VST2 -Plugin abzulegen haben, es gibt nur Empfehlungen von Microsoft.

Die Nichteinhaltung dieser Empfehlungen kann auf Windows zu Rechtekonflikten führen, so dass es notwendig sein könnte Cubase oder andere DAW mit Administrator -Rechten auszuführen. Mit Windows 10 wurde die Rechteverwaltung nochmals überarbeitet, so dass Windows 10 empfindlicher reagiert wenn Dlls oder Programme in nicht empfohlenen Pfaden aufgerufen werden.

Auf dem Mac weiss ich nicht ob es Empfehlungen von Apple gibt, weil ich keinen Mac besitze. Wer auf Windows alle Plugin und dessen Hilfsdateien unter gemeinsamen Dateien abgelegt hat, der braucht Cubase vermutlich nie als Administrator auszuführen. Eine Blacklist in welcher Dlls enthalten sind die keine VST -Schnittstelle enthalten halte ich für überflüssig, es sollten nur Dlls drin sein welche versuchen sich über die von Steinberg definierte VST -Schnittstelle als Plugin zu registrieren aber ein fehlerhaftes Verhalten aufweisen.

1 Like

Jo Ho Ho Ho,

hab gerade ne E.mail von East West bekommen.
Play 5 arbeitet übrigens auch nur noch mit 64Bit Host Anwendungen

Play 5.0.1 Improvements
• Further improved playback performance
• Fixed artifacts and cut notes in offline bounce/freeze
• Added Multi and MPE MIDI modes, now available in the MIDI channel dropdown
Fixed Play being blacklisted in Cubase 9 on Windows
• Fixed saving Wordbuilder phrases on Windows
• ‘Refresh Browser’ command now scans for newly installed libraries
• Fixed a bug where patches would suddenly turn silent in EW Pianos
• Fixed load bar occasionally hanging
• Fixed export progress bar in Cubase not updating
• Fixed a bug where Dark Abbey reverb would be loaded instead of the correct reverb
• Fixed crashes when switching amp presets
• Fixed Mac installer for server OS
• Fixed occasional stuck keys in Play keyboard
• Fixed 1/2 tempo scale saving in 25th Anniversary loops
• Fixed tuning not saving in Ghostwriter