Dik's Plug-in Info Rant (long) 23 Sep 2003

Every year we get a sense of deja vu. It's an endless cycle. Applications capable of hosting plug-ins written to be compliant with one or other generation-versions of the AE plug-in API are updated to a new version and plug-ins that once work in it break.

This is so predictable and - it seems - inevitable, that one wonders why plug-in developers have not, by now, developed streamlined procedures for dealing with it. This means both correcting breakages while hosts are still in Beta and making update information clearly available on websites and listservs so that users know what's go on and can minimise their own time-wastage in getting the new versions and getting them running. This *is* possible. For example, a number of Trapcode plugs broke during AE 6.0 development, and yet compliant versions were available when AE 6.0 was released, and the new versions were well publicised on the Trapcode site, the Trapcode forum and on the AE list. Kudos to Peder.

Of course, Trapcode has only 4 plugs. For larger Developers with sets of 100+, the task is much larger and can be a considerable drain on engineering and QA resources. I'm sympathetic, but - like I say - we all *KNOW* that this is likely to happen and it should be something which Software companies can predict, plan for and budget for.

At the end of the day, Software companies make profits due to the respec and, hence, repeat business from the users. This means support, and support means not only giving prompt advice when users are having software problems, but making sure that information is clearly available to help users minimise time-loss for regular software upgrade issues, such as plugs breaking and needing fixing under AE 6.0.

Consider this. A plug-in Developer might have to check 150 plugs whenever a host undergoes a major revision. But a user who owns even 20% of available AE plug-ins for OS-X has, in fact, 200 plugs to consider and he/she needs to know
these will work correctly when he/she's building their next project to a deadline.

If those plugs work in 3 hosts and each host upgrades every 12 months, then each user can spend a whole lot of time a year riffling through websites and forums trying to make sure that his/her software has no known issues. Multiply this by several hundreds, thousand or tens-of-thousands of users for each plug-in set and it can soon be seen that the effort spent by Developers updating and publicising updates is potentially a small fraction of the potential time-wastage by the user-base.

As I've said, if the capabilities of plug-ins in hosts are to continue to improve, casualties and breakages in available plug-ins are practically inevitable. What needs to be considered, therefore, is how Users' time wastage can be minimized by Developers when it *does* (inevitably) happen and updates are required.

The principle source of information for most Users is Developers' websites (although their attention will most likely be drawn to plug-in updates by posts to listservs and bulletins.)

This means that Users will most likely consult the support area of Developers' websites on a semi-regular basis. This will not just be in response to upgrades made to hosts, but also in response to new or prospective purchases of additional hosts (viz. users will want to know if their plugs also work in those.) Users wishing to make new plug-in purchases are likely to check on this too, to see how well Developers are keeping pace with host development and whether the sets are designed to work with their host/version.

The information which people require is pretty standard. I've recently been trawling Developer websites in order to build up a picture of compatibility with various hosts. These are the pieces of info I was trying to find:

(1) The number and names of plugs in the set
(2) The latest version number of the set and whether it's still on sale
(3) The cost of the set (full and upgrade.)
(4) Whether the set is compatible with OS-9, OS-X, AE 5.5 and OS 6.0
(5) Whether there's a demo available
(6) Whether the set is 16-bit capable
(7) Whether the set is multi-threaded / Multiprocessor-aware
(8) Whether the set uses the Altivec co-processor and/or G5 64-bit
(9) Whether the set runs correctly under FCP 3.0.2 OS-9, FCP 3.0.4 and FCP 4.0.2
(10) Whether the set runs correctly under Boris RED 3.0 (OS-X and Win)
(11) Whether the set runs correctly under Commotion 4.0 (OS-9, OS-X, Win)
(12) Whether the set runs correctly under Elastic Gasket (OS-9, OS-X, Win)
(13) Whether the set runs correctly under Premiere 6.5 (OS-9, OS-X, Win)
(14) Whether the set runs correctly with Premiere Pro (Win XP)
(15) Whether the set runs with Generation Q (with or without Synapse)
(16) What version of the AE Plug-in API the set was written to and any variations which have been made to this spec during reverse engineering....

[Any major hosts or other common info I've forgotten?]

This is normal kind've stuff, which almost all users will want to know at least a percentage of, and yet very few Developer websites catalogue the information in a coherent fashion. Typically, instead of this information being packaged neatly in one place, it's strewn throughout the site in different sections, FAQs, web-stores, demo readmes and so on. Quite often, too, the most basic information like the set's latest version number is not there at all. And even though plug-in compatibility is usually stated as "After Effects 4.1" or "5.0" or "5.5* - "OR LATER* plug-ins may well be broke under 6.0 and still no comments about this being are made clearly on the site.

Even a statement which states that a breakage has been noted and is being worked on is better than no information at all.

Given that there are now over 130 sets of plugs for AE, which can run in any combination of the above hosts and platforms, users are going to need fairly much the same sort of information from *all* the Developers' sites which carry the plug-ins they own, on a few-monthly basis.

IMHO, in an ideal world, therefore, *all* Developer sites should have a template layout for this information, accessed by a standardized link from the Support area of the site. Users could then very quickly surf from site to site and navigate immediately to the information. This would make for a huge time and manpower saving and I hope that in any future meetings between Developers (e.g. at venues like IBC and NAB) and through groupings like the plug-in developer's Alliance, such a template can be developed and instituted.

Of the sites I've seen, Revison FX probably offers the clearest presentation of upgrade information and host support (kudos to Pete and Pierre) with the names of host support and the latest version numbers (with version history) clearly laid out in one place. Even so the plug-by-plug info isn't entirely consistent and I don't see clear statements of AE 6.0 (as on the RedGiant site) and FCP 4.0.2 compliance (nowhere that I've seen) in that information. There's other sites with good clear info (Synthetic-Ap and Trapcode come to mind, but I'm sure there're others) too - but the majority are not so good.

Statements of host support are often lacking (e.g. Trapcode only has official support for AE, with advice to download a demo and try for yourself in other hosts - imagine the man-hours spent on that! - Digieffects also has no support for anything other than AE, on the basis that it's up to the other hosts to reverse-engineer the AE API so that DE plugs work properly with no effort on DE's part. I wonder how many people will buy plugs for FCP or Commotion or Premiere or RED on that basis?)

IMHO Developers should budget for the R&D, QA and Beta-testers necessary to be able to have versions of their plugs running in several common hosts, since this adds value to their product.

This often isn't easy, and may be impossible, given that AE is now on a generation 6.0 API while FCP (for example) is only running a bastardised adaptation of the
3.1 API. Advanced AE plugs with sophisticated custom controls may thus be impossible to port to FCP. I do believe that non-custom-controlled versions *could* often be developed, though, and incorporated into the single-price installer. And if it remains a problem, how about applying pressure on Apple (as a body of Developers) either to reverse engineer later versions of the AE Plug-in API, or adopt a more powerful non-Adobe API, along with other host Developers? There must be ways....

Whether or not the Developer chooses not to support many hosts, it's still just as important to convey this information clearly and in standardized layout and location, so that users can quickly see which hosts *are* supported.


Of the various bits of information I was seeking as I trawled sites (which I listed above,) these are my experiences and comments about common flaws in site layout, which I hope will be of value to Developers when planning improvements in information flow.

(1) The number and names of plugs in the set

The names and descriptions of plugs can usually be found somewhere on the site, but normally it's under "Products." For people checking on upgrades, the info they need is probably just a number and a simple list of plugs, so they can check that their plugs match up. It's not unusual for Developers to add plugs to sets, and it's nice to see clearly that this has happened. (E.g. DFT Composite Suite expanded considerably between the last two versions, as did DFT 55mm.)

(2) The latest version number of the set and whether it's still on sale

I suppose that if products are abandoned and no longer supported that it's not surprising that Developers should try to hide it away and hope that people forget about it. This is unhelpful, however. A clear statement that the product is no longer supported after version X.x might spark some irate emails, but for most Users it's a much greater time-saver than trying to sleuth-out the truth (which time-wastage is likely to engender even more irate emails ;-) when Developers are not being up-front about it.

It's also amazing how few sites give a clear indication of the latest set version number, both on the plug-ins themselves and on the upgrade area of the site. Version numbers are really the only clear way of seeing whether you have the latest incarnation of a set. BUT if you don't know the number of the set you have and DON'T know the number of the latest download on the Developer's site, how do you know whether you need to upgrade or not. By downloading and checking the date? Of File>Info?

Far too often you can open the "About" hyperlink in the AE Effects Control Window and get a bland About box which:

- has a cool design but no version number whatsoever - has no cool design and no version number whatsoever - (more commonly) a cool design or not with a 2-digit version number. This is often equally unhelpful, since critical changes may be reflected in the 3rd. part of the version number. E.g. there are a number of plugs which need version 1.5.1 or 1.0.1 to work properly in AE 6.0 and yet the About box may still show both as 1.5 or 1.0. Basically this is lazy programming and it can cause Users considerable time-wastage.

It's amazing too how many sites don't have the latest version number, the date this was released and the reason why it was released clearly stated at the beginning of the support area for that set. Sometimes the version number isn't stated at all. In other celebrated instances (e.g the Pinnacle site when Image Lounge, Composite Wizard and became OS-X compliant) the version number is inside the security screen where you have to fill in your life history and zip code [HK doesn't have them] information in order to get into the download area and *only there* do you find out what the latest version number is (oh I've already downloaded that one and I just wasted 10 minutes filling in my life history ... again...)

Commonly too, sites just post a 2 digit version number, not a 3-digit number. And if that weren't enough, you can often get sets which are downloaded as 1.5 but which have 1.1 in the About box (Delirium) or which have separate version numbers for the plug-ins than for the set, so that even if you see 1.0.1 in the about box, the set may actually be 1.1.

And occasionally you may find that only a few plugs in the set are upgraded (Tinderbox 3) so if you ever have to reinstall, you need to remember to install both 1.0 but then overwrite 3 of them with 1,0V1.....

My suggestion would be that if any plugs are upgraded then the whole set should be written with the new version number in the about box and the file resource, so that it's clear that the plugs belong to that set. Version numbers in the About box and the upgrade area of the site should be X.x.x format, and the version numbers should be stated clearly in the open area of the support site, not in the login protected download area. There may be security issues with this. If so I'd love to hear Developers' points on this.

Good sites also have a development history per set. Most of the time you don't need this, but if you find the latest version does not work with your current host, it's useful to be able to check the history so you can see what changes were made and which version of the plug set *was* designed to be compliant with that version of the host. Also such info as when additional plugs were added (and so on) may be useful in checking that your own set is up to date. Ideally there should be a version history *per supported host.*

I feel that the AE API could be helping more here. It should be required of plugs that they provide a version number along with the match name, when they are loaded. This data should also be available via AEGP calls to AE, so that scriptable software such as UA and Koala Lumpor can interrogate it, and so that AEGP plugs could be written to access Developers websites and auto-update.

(3) The cost of the set (full and upgrade.)

This is usually show in the Developer's "Store" or sales area. For people who are looking to upgrade it would be simpler to have the new and upgrade prices stated in the upgrade info area.

(4) Whether the set is compatible with OS-9, OS-X, AE 5.5 and OS 6.0

This is obviously needed by users, and is usually stated, although it may be very late appearing (viz. Developers don't announce AE 6.0 compatibility until a version compatible with AE 6.0 is available.) In fact, most Developers have access to host Beta lists (athough this may not be until very late in the cycle if they also develop their own hosts which could be seen as competitive with the one in question.) This means that they should at least be able to find any compliance problems before release and be able to state the compliance with this version of the software, their intention to fix problems (or not) and a rough idea of timescale for this *immediately* the host is released. Very few do.

(5) Whether there's a demo available

This is usually found as a link from the Product area. This is OK, but people thinking about upgrading may well want to check out the latest demo first, so it's nice to have a link from the upgrade area too.

(6) Whether the set is 16-bit capable

This is commonly not stated in summary or tabular form, but hidden away in deep areas of the product details or FAQs. It's an increasingly important factor for many users and should be clearly stated if Developers want to earn more sales and upgrade fees.

(7) Whether the set is multi-threaded / Multiprocessor-aware

This is even less clearly stated. It's probably impossible to get a profile of which plugs use MP from Developers' websites.


(8) Whether the set uses the Altivec co-processor and/or G5 64-bit

AFAIK only Synthetic-Ap make clear statements about this. Maybe that's because they're the only ones to make calls to the Altivec co-processor, or maybe the others just don't tell us. It's early days for info on codings which use the full power of the 970 chips, but I'm no more optimistic about clear statements of this than about Altivec.

(9) Whether the set runs correctly under FCP 3.0.2 OS-9, FCP 3.0.4 and FCP 4.0.2

(10) Whether the set runs correctly under Boris RED 3.0 (OS-X and Win) (11) Whether the set runs correctly under Commotion 4.0 (OS-9, OS-X, Win)

(12) Whether the set runs correctly under Elastic Gasket OS-9, OS-X, Win

(13) Whether the set runs correctly under Premiere 6.5 (OS-9, OS-X, Win)

(14) Whether the set runs correctly with Premiere Pro (Win XP)


(15) Whether the set runs with Generation Q (with or without Synapse)

If a plug-in set is officially supported under other hosts at all (and far too few are) then this info will probably occur somewhere on the site, although (again) there are a huge variety of places where you might find that information. A simple tabular approach would be clearer.

Typically even when plugs are listed as being supported, they are only stated to be supported for a whole number version of a host. This may not be enough. E.g. plugs which worked under FCP 3.0 (e.g. Delirium) did not work properly under 3.0.2 (and AFAIK still don't ..... ) Users need to know issues with dot releases too.....

The hosts and gaskets are often at fault here too. I doubt if the Elastic Gasket listing is up to date for example ... or the Boris RED listing. There seems to be a "responsibility trap" at work here: "It's the host Developer's responsibility to test and publicise this. No it's the plug-in Developer's responsibility. No it isn't it's the ....." Of course, plugs working in hosts add value to both, and it's probably time more effort was put into testing and codification by both sides.....


(16) What version of the AE Plug-in API the set was written to and any variations which have been made to this spec during reverse engineering....

Again a fairly basic thing and yet you almost never see it. If you know this, then you can have a reasonable guess at what plugs will work.

There's probably more things which could be incorporated in the upgrade / feature summary area of Developer websites. If anyone can think of any they feel I've missed, please share. I'd also like to hear such things as potential security (anti-piracy) issues which Developers feel have a bearing on more standardization to information.

As always, this is just my POV and I hope there will be other angles presented which will be of benefit to Developers designing information areas for sites.....

Dik