Archive for March, 2006

User-to-User forum

So, there’s a U2U forum for AE plug-in developers. Cool!
Haven’t yet figured out a way to block the use of graphical emoticon substitution in postings.

Where the magic happens

By request…
The CRT is now flat-screen, but otherwise this is where I spend entirely too much time.
I can't believe you sit in that sty all day.

Advice from people smarter than me

For a better understanding of why you should update your effects to be 32bpc (and, of necessity, adopt the new-fangled SmartFX API messaging), read this bit about After Effects 7.0 and the possibilities for 32-bit color fun.

More XCode debugging details

Set breakpoints in your plug-in.
Build it into AE’s plug-in directory.
Launch AE.
From XCode’s debug menu, “Attach”, and select AE.
Doesn’t work?
Try these instructions. Oh, and buy something from Unsanity, because they’re cool.
Now that your project has defined a debug executable that points down inside AE’s package to the actual executable (gasp!), does XCode magically realize that it CAN attach to After Effects, even though it said it couldn’t a moment ago?
It does for me.

Bigger Picture

So, XCode-related outbursts aside, here’s a high level view of where we are, and where we’re headed.
Our NAB presence will be (unsurprisingly) all about the Production Studio. Adobe likes suites. If you’re a developer who’s exhibiting at NAB, and you haven’t already been contacted by me or Adobe marketing, please send me information about your booth presence, and what Adobe product(s!) you’ll be running.
I plan to release updated SDKs before NAB. The sample projects will have been updated for Microsoft Visual Studio .NET 2005 and XCode 2.2.1. I’ve added a couple suites to AEGP_SuiteHandler, but the AE-related headers will not have changed. The docs will have undergone only minor changes. I’m pressing ahead with my new InDesign-based “tips ‘n’ tricks” document…wish me luck.
For our position and schedule for releasing Intel-compatible Universal Binaries, see:
http://www.adobe.com/products/pdfs/intelmacsupport.pdf
As always, feel free to ask me AE-(and-hopefully-API-)related questions.
Oh yes, for more (and better) high-level Adobe and After Effects Marketing Vision, see Steve Kilisky’s blog.

( AE 7.0 + debugging) * (XCode / OS X)

Let me know if you’re having problems; debugging seems reliable for me now.
Kelp: It’s what’s for dinner!
Three Mile Beach, Santa Cruz.

More XCode fun

Perhaps those developer shops with > 1 programmer can benefit from our experience using XCode in a source controlled environment.
– When an XCode project is modified by someone else (i.e. file added, etc), you need to (1) quit XCode, (2) run your source control, (3) re-launch XCode. If you simply close the project but keep XCode running, the changes may not get picked up by XCode. It has a very good memory.
– Some project settings that you might not expect are saved *with* the project file. This includes breakpoints. If you’re making changes to a project, before checking it in make sure to clear *all* your breakpoints before checking-in, otherwise everyone will er… benefit from your settings (hint: this is not a good way to make friends).
You can clear breakpoints using the Debug > Breakpoints window. If you have some difficulties clearing a breakpoint by clicking on it, select the Debug > Remove Breakpoint command. However…
– Breakpoints are *per project*. So, if you (or someone else, see above) set a breakpoint, say, in a core library project, you will not be able to clear it while you are in the client project. How can you tell which project you’re in? When you bring the Breakpoints window up, the title bar of the window will start with the name of the project. Note that this is the case even if the project is closed. To clear a breakpoint set in another project, open that project, then with the project window frontmost, select Debug > Breakpoints. You can now remove those breakpoints (select them in the Group and Files column and press the Delete key).
– Finally, since breakpoints are saved with the project, once you’ve added or removed a breakpoint the project file is now dirty. When closing the project you will be asked if you want to save the changes. Say yes.

Wow, comment spam.

Truly, I have arrived.

‘can’t find entry point’ of plug-ins built w/XCode?

If you’ve tried to port an existing effect plug-in to XCode, you’ve no doubt seen the pedantic “main() must return int” warning. I found a couple gotcha’s when changing the name of the entry point function; fixing these 30 or so times really drove the problem home to me.
First, update the name of your entry point function (duh). Then, change the name of the entry point function specified in your plug-in’s PiPL. While I was there, I stripped out the #ifdef __MACH__ business; the current 7.0 SDK will be the last with CFM sample projects.
Everything builds and links correctly, the plug-in loads, but when it’s applied AE can’t find the entry point? Name mangling.
Remember that CodeWarrior exported the entry point based on project settings. For the sample projects, I’ve gone through and made sure the entry point function was exported (declared) using extern “C”:
extern “C” {
DllExport PF_Err
EntryPointFunc(
PF_Cmd cmd,
PF_InData *in_data,
PF_OutData *out_data,
PF_ParamDef *params[],
PF_LayerDef *output,
void *extra );
}
Presto! Entry point found.