Bringing Native Plug-Ins to Final Cut Pro

In the transition from Final Cut Pro 7 to Final Cut Pro X , Apple's professional video editing app lost direct support for FxPlug plug-ins. Visual effects plug-ins may only be delivered to customers when wrapped inside Motion Templates.

Templates bring Motion’s realtime graphics inside Final Cut Pro as effects, transitions, titles or generators. Motion Templates are not limited to built-in features: they may include any combination of native plug-ins. Parameters from those plug-ins can be published to allow customization in Final Cut Pro.

Implications for Native Plug-in Developers

Motion Templates are currently the only way to deliver products based on FxPlug plug-ins to Final Cut Pro users. Certain limitations are imposed by this technology:

  • Slower to load and render than native plug-ins: the extra work required to load and render a Motion project is unavoidable.
  • Poorer output quality than it is generally possible with a native plug-in: media may be field-doubled, scaled, cropped, etc. thereby introducing filtering artifacts even if the plug-in may have been inherently capable of processing pixels and at their native aspect and display ratios. Output quality varies according to the version of Final Cut Pro used and the snapshots included with each Motion Template.
  • Many inherent advantages of plug-ins are lost: a native plug-in may be capable of handling any combination of project resolution, bit depth, pixel aspect ratio and display aspect ratio, but these abilities are lost in the process of wrapping the native plug-in inside a Motion Template. Developers are forced to create multiple snapshots within the same template to handle a fixed set of aspect ratios.
  • No parameter grouping: even as FxPlug allows for parameters to be grouped together to provide a better user experience, the Motion Template specification contains no official method for publishing parameter groups or even creating groups in the context of your published parameters. It is extremely hard for developers to deliver complex-but-usable plug-ins, and even harder for users to learn and use any effect where a large number of parameters is unavoidable.
  • Image parameters cannot be published: it is impossible to directly publish an auxiliary image input, to be available as a drop zone in Final Cut Pro. Developers have to create drop zones in Motion, whose content is fed to the image parameter. Because the user is ultimately interacting with a drop zone rather than the original parameter, it is impossible to apply dynamic UI rules to these drop zones. The developer has no choice but to leave these drop zones visible in the inspector even when this makes no sense within the current effect configuration.
  • Publishing pararameters is a tedious, error prone task: the order in which parameters are created by your plug-in is ignored. The only order that matters when wrapping a native plug-in inside a Motion Template is the one in which parameters are published. This creates the need to publish your entier parameter structure in each template. Since parameter groups or image parameters cannot be published to begin with, it creates unnecessariy duplication of work for the developer, and leaves limited options to bring plug-ins to Final Cut Pro.
  • Limited Dynamic UI: it is common for plug-ins to disable or hide parameters that are not applicable within the current context in order to make the product easier to use. Any work you may have done to create these dependencies does not immediately translate to Motion Templates, as the developer is forced to go through every possible combination of the plug-in in order to publish its parameters.
  • Templates cannot be deployed or installed easily: developers and end-users have additional responsibilities to ensure that visual effects can be found and loaded by Final Cut Pro. Multiple install locations are possible. Effects are identified by their installation path rather than by a reliable identification system. Reliable, unique identification as provided by UUIDs in the FxPlug specification has no equivalent in Motion Templates.
  • Templates may be modified at will: earlier versions of Motion Templates have no provision to avoid accidental modification of your effects by end-users, and consequently no guarantee that two users would be using the same version of any given effect. Users have no way to know if an effect is as supplied by the developer, or a version modified via Motion. Imagine how much harder tech support can be when you do not know if the user is actually using the effect you distribute, or a variant thereof, while being unable to reinstall a clean version of your product for fear of wiping their changes. Later versions of Motion Templates have addressed this problem.
  • Templates are inherently open: the architecture contains no provision which prevents more advanced users from editing and/or redistributing your templates. This is not a big issue when using Motion Templates solely for the purpose of wrapping and delivering native plug-ins, but it leaves anyone creating effects based only on built-in features with no protection for their intellectual property.

The above is only a selection of the more serious limitations developers must face when bringing native plug-ins to Final Cut Pro. To help make Motion Templates a more viable platform for visual effects development and distribution, FxFactory uses a technology called FxTemplates:

Introduction to FxTemplates for Motion Template Developers