Is Python the future of Final Cut Pro X workflow?

So, this is a little more geeky than is normal even for this blog, but I ran the Unix ‘strings’ command on the Final Cut Pro X binary. This command tries to extract things that look like bits of human-readable text out of binary files. Used on Cocoa apps like FCP X, it can often turn up the names of internal methods, classes, etc. Here are some of the more interesting strings it found:



This suggests partial or stub implementations of XML import and Python scripting features are already present. As far as the XML import goes, my guess is FCP X was supposed to ship with XML import, and this was the solution for bringing in FCP 7 projects… but it wasn’t done in time and they decided to ship anyway.

Notice that there’s no XML exporting, however. (Except maybe clip lists?) What’s the deal with that? Well, Python might actually explain that. Normally if I saw references to Python like this in an app, I’d assume it was merely being used internally by the app, but here it appears along with references to plug-ins. My guess is that the plan is to allow third-parties to write Python scripts that hook directly into FCP X. This could, if implemented the right way, be far more powerful than simple XML exporting, because it could give third-party tools access to FCP X’s functionality, not just to static project data.

We’ll have to wait and see what comes of this, but these indicators do look promising.

This entry was posted in Products, Tech Commentary and tagged . Bookmark the permalink.

14 Responses to Is Python the future of Final Cut Pro X workflow?

  1. David Sander says:

    I’ll be interested to see what Automatic Duck makes of that little window for functionality. Their upgrade released the other day announced the ability to convert an FCPX file to AAF/OMFs for ProTools, but there are no indications yet of any ability to translate FCPX to XML (or better still a ready-to-open After Effects/Shake/Flame etc project file), which eliminated FCPX from any workflow I can be involved with, as I use AEP CS5 for my compositing, grading, graphics and finishing of features cut in FCP.

  2. Chris Kenny says:

    I saw that announcement from Automatic Duck. I’m extremely curious how they’re tapping into FCP X to get that data out. Perhaps they already have early access to a Python API or some other mechanism that will be opened to more parties in the future?

  3. Martin Baker says:

    Automatic Duck are getting access via drag and drop. If you drag an FCPX Project onto a diagnostic tool such as Pasteboard then you get this:

    PasteboardRef: 5382656 ItemCount: 1 Index: 1 item ID: 789514 "dyn.ah62d4rv4gu8yqvwmr3wgn8cuqf4gu64bsrcgc7dbnbbg82pwqvnhw6df" "FFIndexPathsAsDataPBoardType" '' ______ 418 bplist00 X versionX objectsY archiverT top U null V clas

    Doesn’t really help much, I admit!

    • Hey Martin,

      I haven’t had time to dig into the drag target stuff. Have you had a chance to decode the content of that binary plist?


      • Chris Kenny says:

        I have. It’s serialized object state written out by CoreData. I haven’t gone through all of the different object types yet, but the stuff CoreData writes out tends to be fairly incomprehensible to humans, as a general rule.

        I’m guessing Automatic Duck has access to some Apple documentation or maybe even an API that’s letting them read this stuff.

  4. Ron says:

    I just hope Apple Open Source’s Final Cut Server would hate to see such a great product go to waste collecting dust!

  5. Jack says:

    I was at the FCPUG in London last night. The official word seems to be that Apple is not interested in pursuing XML support, but will leave it to third-parties. The implications of this are distressing because it means there will be no “official” XML specification any more.

    • Chris Kenny says:

      At the same time, though, this lends support to the notion of FCP X getting a real API, not just the ability to export static XML files. While the loss of a standardized open file format will have some downsides, an actual API would provide far more power. It would certainly be a killer feature for our internal workflow needs.

    • The arrogance of Apple’s disinterest in the needs of the broadcast professional is highly disconcerting…

  6. Pingback: Jonathan Eric Tyrrell @

  7. Good, bad, or indifferent, if Apple opens up the FCPX API, then I think that means their business model for the pro video apps is going to be in line with the iPhone. Think about it, the iPhone is a great tool on it’s own, but it’s lacking features. Thus, the App Store.

    Speculation, of course, but Apple make the overall product. Sure, they’ll add and remove features at will. But with a robust dev market, we’ll be able to add back in features like edit to tape and capture, etc…

    And yep, we’ll have to pay money for it – but my guess is that you’ll think – hell, it’s 49.99 to edit to tape – that’s a pittance in comparison to the job I would have to turn down otherwise.

    Just my 2 cents. What say ye?

  8. Pingback: Why Premiere Pro could use scripting | Creative Impatience

  9. Pingback: Missing | post post

Leave a Reply