Final Cut Pro X from a Developer Perspective

I've already mentioned The Good, The Bad and The Ugly of Final Cut Pro X but when it comes to developer features, there's a lot more to like.

Chris Kenny has been doing some delving and discovered that there are references to Python and AppleScript in the Final Cut Pro X app. This would be a big step up from the current method of sending commands via Apple Events.

There are also references to XML import and Final Cut Pro XML import, which implies that they will be two different formats. This makes sense, as the structure of FCPX projects has changed significantly (no more bins and no concept of tracks for instance) and there is a greater focus on metadata.

Neither of these are publicly accessible right now but they show that Apple has at least experimented with these functions and it is likely that they will be enabled in a future release. There has been speculation that import of FCP7 projects or XML may never come as the project formats are too different, but I think it's likely that we will at least see an FCPX-specific exchange format at some point in the future.

Final Cut Pro X now uses the Motion engine to render effects, which means that plugin output is now consistent between Final Cut Pro and Motion - something that was not the case in previous versions. Developers need to wrap their Motion plugins as Final Cut Effects in order for them to show up in Final Cut Pro X.

Other notable changes include more control over plugin user interfaces, support for multi-threading, keyframing, undo and bezier paths. These have been requested for a long time so it's great that they're now here. Thanks to Darrin Cardani and Paul Schneider at Apple for listening to the needs of developers.

Final Cut Pro X and Motion 5 require plugins to be compiled as 64-bit so most users' plugins won't be compatible. This is only a temporary problem until plugin developers catch up and the benefits of a 64-bit environment and FxPlug 2.0 will make it worthwhile. (There are, of course, some bugs in the implementation as would be expected in a 1.0 release.)

Just before Final Cut Pro X was unveiled at NAB earlier this year, I wrote a post about my Top 5 Developer Requests for the Next Final Cut Pro.

Storing settings in preference lists was number one and, as expected, this was implemented. While the reasons for wanting it so badly (mainly for programmatically changing scratch disk locations) are less important in Final Cut Pro X, we can still do a lot of things with it.

Making the Final Cut Pro project format more open was second on the list. This one is a little more complex because on the one hand, it's in SQLite format which makes it readable by the sqlite3 Terminal command but on the other, Core Data assumes that no-one other than the owning application will ever touch those files and so it's very easy to corrupt it if you're not careful. Also, while the SQLite format offers some predictability, Apple are free to structure the database any way they see fit and change it without notice in future versions. I've written a basic filename parser but I'm going to wait for official documentation or an API before doing anything more substantial.

Third, fourth and fifth on the list were requests for more API control. This is not in the initial release of Final Cut Pro X and remains to be seen if it will be in future versions.

Of course, I wrote this on the assumption that FCPX wouldn't remove any developer features that were in the previous version. While the developer features are sparse in the current version, the future looks bright, especially as it appears that Apple is expecting third-party developers to fill in many of the gaps in FCPX's feature set.