In the transition from Final Cut Pro 7 to Final Cut Pro , 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. Many 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 in their native shape (anamorphic) and at any display aspect ratio. Output quality varies according to the version of Final Cut Pro used and the snapshots included with each Motion Template.
- Many advantages of plug-ins are lost: a native plug-in may be capable of handling any combination of project resolution, frame rate, 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, locked to a single frame rate.
- 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 entire 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.
- Effects cannot tell when rendering a full resolution frame: in apps that support plugins natively, the concept of a downsampling factor allows plugins to know if they are processing frames at native vs reduced resolution (1/2, 1/4, etc.) This is a common occurrence both when users change Canvas resolution explicitly, or when host apps are dynamically adjusting playback quality to avoid dropping frames. In Final Cut Pro the downsampling factors cannot be relied on for making this decision, since the app has hi-jacked the meaning of those values. For example, when a HD snapshot created at 1920x1080 is applied to an UHD clip, Final Cut Pro will use a scaling factor of 2.0 when rendering at full resolution, and 1.0 when rendering at half resolution. Relying on that same snapshot, a plug-in that observes a scaling factor of 0.5 will not be able to tell if it is applied to an HD clip at 1/2 resolution, or to an UHD clip at 1/4 resolution. Similarly, if you create an 4K snapshot to handle 16:9 aspect ratio, and the plug-in observes a scaling factor of 0.5, it cannot know if it is processing a 4K frame at 1/2 resolution, or if the user has applied the effect to an HD clip.
- Effects are subject to math rounding problems: every snapshots in your Motion Template is created at a given frame rate, and when the effect is applied to a clip with a different frame rate, it will be subject to problems that derive from the often inprecise mapping performed by Final Cut Pro. For example, let’s take a plug-in that comes with custom on-screen controls to manipulate its parameters or other internal data structures. In FxPlug, this means that two plug-ins will be active: one responsible for the custom on-screen controls and one responsible for rendering frames. When the effect is based on a snapshot created around the NTSC frame rate, and applied to a PAL clip in an NTSC timeline, Final Cut Pro will allow the on-screen control plug-in to observe and change parameter values at the NTSC framerate, while the effect plug-in will observe and change parameter values at the PAL framerate. This makes it impossible for both the on-screen control plug-in and its effect plug-in counterpart to set keyframes at exact frame boundaries, or even to agree on what the best frame rate to use is.
- 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