FxFactory Developer

This document describes a few important steps that need to be taken in preparation for a product release.

• Make sure that you don't have any unmapped or undefined parameters in your plug-ins. These parameters appear with a red or yellow status indicator in FxFactory: You can also get automatic warning about these parameters by enabling the “Warn when development-related errors occur” option in the FxFactory Preferences window, under the “Development” section:
• Make sure that your parameter names only contain characters that can be safely encoded using the default MacRoman encoding. This means symbols should not be included. Although FxPlug hosts support the full range of characters allowed by Unicode, After Effects is limited in that it still uses the old MacRoman encoding for parameter names for all Western-European languages and MacJapanese when running on systems where Japanese is the current language. Both these encodings do not allow the full range of symbols that you will find in the Unicode table.
• Compare the ranges of your slider parameters with the ranges allowed by the corresponding input in the composition. When FxFactory creates a parameter for a newly-published input, it guesses what the appropriate range should be based on information that comes from the Quartz Composer API. Unfortunately this guess is not always appropriate, as shown by this example: This parameter was created automatically from a numeric port with initial value of 10.294 and no upper bound ¹⁾. Because of this, FxFactory could not make a meaningful guess as to what the upper range for the slider should be. Since the parameter corresponds to a pixel-based value for a blur, a Maximum value of 100px or 1000px would certainly make more sense than the value chosen by FxFactory.
• Check the parameter names for typos. If English is not your native language, make sure that the choice of words makes sense to a native English speaker.

FxFactory gives you numerous options for linking a plug-in to its documentation. The most common choices for embedding documentation are PDF and HTML files. When embedding documentation as HTML:

• Check your documentation for typos, especially those caused by the use of reserved chacters in the HTML source. One example among many: HTML does not allow ampersands to be used directly. They must be entered using the character sequence “&”.
• Make sure that all links are valid.
• Make sure that your CSS files use fonts that are available on all systems.

• Assuming that you've done all your development on the most recent version of OS X, find out if your new product works on Mac OS X 10.6.3 as well. Set minimum product requirements accordingly. ²⁾
• If your plug-ins are declared as capable of 16-bit or 32-bit float rendering, make sure that they are indeed capable of rendering at those bit depths in all hosts, and on all versions of Mac OS X supported by the product.
• If your plug-ins are declared as capable of rendering at the native aspect ratio of the source media (interlaced or progressive, square or anamorphic) test your plug-ins with a variety of media: NTSC/PAL SD, 1080i HD, 720p HD, etc. ³⁾

• Chances are the default watermark created by FxFactory will not cut it for release. Embed an asset that you wish to use as the product watermark. If this is not your first product, you can simply copy the watermark graphic from one of your previous products to save time. Watermark graphics should best be designed to cover about 25% of the frame at 50% opacity. Your company logo is a good starting point for creating a watermark graphic.
• Submit the FxPack and/or FxTemplates to us and stop any further development on the product. We will prepare the product for commercial distribution and send it back to you, at which point you can resume working on the copy that has been returned to you. Doing so saves time, since it allows us to prepare the product for commercial distribution only once.