Man kann in jedem Fall festhalten, dass OFX DER Plugin Standard für hochgradig spezialisierte Anwendungen ist, und da zähle ich
in jedem Fall die Produkte von Assimilate, Quantel, The Foundry und teilweise eben auch Blackmagic (Resolve + Fusion) dazu.
OFX liegt auf der Hand, weil es für diese Hersteller keinen Sinn macht, sich in proprietäre Modelle reinzuhängen, deren Standard
nicht offen dokumentiert wird.
Dass die drei großen "A"s ihr eigenes Süppchen kochen liegt an der Verbreitung der Software selbst und der aktiven Unterstützung
der PlugIn-Hersteller. Dass NewBlue nun den Weg geht und OFX mit Hilfe der Bridge in Anwendungen bringt, die diesen Standard
eigentlich nicht nativ unterstützen, ist eigentlich recht clever und im Einzelfall sicher sehr hilfreich. Bei den drei großen "A"s gibt
es aber wenigstens eine leistungsfähige PlugIn-Schnittstelle, weshalb diese eben auch nicht zwanghaft auf den OFX-Support
angewiesen sind und daher nicht alternativlos einem einzigen PlugIn-Hersteller ausgeliefert sind. Edius hingegen ist das sehr wohl.
Die AFX-Schnittstelle war ein Reverse-Engineering. Die Entwickler haben versucht, eine nicht näher dokumentierte Schnittstelle
nachzubilden, die die Befehle der Plugins empfängt und umsetzt. Dafür muss man sagen, hat es dann doch recht gut geklappt.
Da zolle ich Respekt für dieses ambitionierte Unternehmung! Bei OFX sieht die Sache aber anders aus. Die Schnittstelle ist offen
dokumentiert und die Herausforderung an die Entwickler ist die, die Möglichkeiten der eigenen Engine mit den Möglichkeiten der
OFX-Schnittstelle zu "verdrahten". Bliebe das in der Hand vcn GV, wären Anpassungen auch ein kleineres Problem. Obendrein
würde GV auch selbst die mit der Zeit wachsenden Anforderungen an die Edius-Engine wahrnehmen und nicht erst über Stellvertreter
Parteien, wie es NewBlue wäre, vermittelt bekommen. Wenn GV das mit der gleichen Aufmerksamkeit belohnt, wie wir das von
Feature Requests kennen, dann habe ich eine Ahnung davon, womit man eben alles nicht rechnen darf.
Mit der Auslagerung der OFX-Schnittstelle beraubt sich GV der Möglichkeit, am Zahn der Zeit zu bleiben. Damit wird die OFX-
Schnittstelle auch für GV nur eine sekundäre Baustelle, die eben auch nur wie eine sekundäre Baustelle behandelt wird. Obendrein
landen die Bedürfnisformulierungen der User bei NewBlue und nicht bei GV direkt. Somit ist GV diesen Einflüssen von Userseite nicht
mehr direkt ausgesetzt, was wie eine Innovationsbremse wirken kann.
Auf den miserablen Workflow, den ein PlugIn im PlugIn mit sich bringt, will ich gar nicht mehr eingehen. Für mich ist es der Start in
ein Patchwork-System, das GV den Raum gibt, am Core nicht mehr viel rütteln zu müssen, der Innovationsdruck wird quasi abgeschaltet.
Hier wird ein Punkt, für den man sich eigentlich selbst verantwortlich zeigen sollte, bei Inkaufnahme eines unbequemen Workflows faul
ausgelagert!
Meine Meinung!
Jim