The present and future of post production business and technology | Philip Hodgetts

Apr/11

17

Why I think I was wrong about an XML Project format for Final Cut Pro X

When I summarized What I thought I knew about Final Cut Pro X, one item was that the Project format would change from being a Binary format to an XML-based format. Then I got a couple more data points that have led me to rethink that.

The primary data point happened last night when rewatching the Sneak Peek on YouTube and heard Peter Steinauer (Architect of Final Cut Pro) say about Smart Collections:

“The collection is based on Queries”

Queries mean databases in my mind.

Then I was playing in iMovie ’11 – because that’s the closest I can get to Final Cut Pro X right now (even though it’s only very superficially similar), and realized it has no “Save” command in the File menu. In Apple’s Address Book and iCal you don’t have to save changes, they’re just there! Those two applications are built using databases (Cocoa’s Core Data).

The only other NLE that had no Save command was Avid’s now defunct Liquid. The demo artist took great pleasure in pulling the plug on the computer mid demo. After a restart the project picked up exactly where it was when the plug was pulled. No work lost, because it was tracking every change in the background.

Since Apple seem to be adopting the best-of-breed for every major NLE feature, according to those many writers who wanted to show how Apple was “only playing catchup”, then why not a best-of-breed project format based on a database?

It’s a long shot call, based on too little information. I’m very aware of the risk of taking a single statement in a presentation and trying to read too much into it, but if I had to place a bet right now, it would be that the project format is in some way related to a database.

That makes sense, as it was already most likely they were using a combination of media-file based metadata and database for tracking media (very similar to Media Composer’s approach), so why not do it for the whole project, with the advantage that every move and change is stored automatically.

If that’s real, then a true history palette (or similar) would be possible.

Probability: 50/50.

No tags

17 comments

  • Ryan P · April 17, 2011 at 5:00 pm

    OSX Lion is based around the concept of killing the “save” command. It’s no long shot to assume FCP X is going to hold up to those company wide standards.

    In fact, it’s a bullet point feature for Lion:

    http://developer.apple.com/technologies/mac/whats-new.html#auto-save

    A OS-wide API for auto saving might also make it easier for multiple apps to trade files & projects. Since they would likely all know where to look automatically, and have the ability to keep track of versions. So in theory, you could have multiple editors or users working on different aspects of the same project, and everyone gets updates in real-time, on the fly. Who needs Final Cut Server anymore? I never liked the program anyway. Not user friendly at all. ( and yes, that matters even with “pros.” ) Not enough integration with the Final Cut Suite.

    • Admin comment by Philip · April 17, 2011 at 5:04 pm

      thanks for the note Ryan. I’d forgotten that announcement. BTW, Final Cut Pro X will be doing it on Snow Leopard as well.

      I think Final Cut Server still has a whole lot of workflow automation and metadata storage than the new Final Cut Pro. Time for an update to Final Cut Server though.

  • Piers Goodhew · April 17, 2011 at 5:35 pm

    Database is certainly possible, but you could also argue the “query” searches also just look like good ole iTunes smart playlists which are spreading everywhere and merely rely on having your data indexed.

    • Admin comment by Philip · April 17, 2011 at 5:51 pm

      True, that’s why I give it 50/50 possibility.

  • Greg · April 17, 2011 at 6:22 pm

    Ryan P, I had that thought too. Except that the Auto-Save technology isn’t new to Lion – it’s available optionally in Snow Leopard for document-based applications too. For example Text Edit has a preference for Autosaving. I guess the change is that in Lion it’s not optional anymore, which is a good thing since it’s a great feature!

  • Scott Simmons · April 17, 2011 at 6:48 pm

    This sounds like a good call. Also consider that timeline indestructible that FCP X will have (a very nice feature). If it works the way it looked then there has to be some kind of data tracking going on throughout the project.

  • Jeff Handy · April 17, 2011 at 6:59 pm

    It’s an interesting thought. Along those lines, if there is a database back-end, I would think Apple would add as an option, a FCsvr interface which would directly read and write to the live/shared db FCsvr provides.

  • Andrew Richards · April 17, 2011 at 7:36 pm

    What I want to see, if in fact FCPX can speak database (SQL?), is FCPX acting as a direct client of Final Cut Server. No more separate clunky Java client, just direct interaction with the content database from within FCP’s UI. That would be killer.

  • Ryan P · April 17, 2011 at 7:36 pm

    @Greg

    Auto save tech certainly isn’t new. But what is new is that Apple is pushing it out as an API ( i assume ) that works throughout the entire OS. Including Time Machine. That’s at the core-system level( ish ). The fact that iLife/iWorks apps already have it at the app level just means that Apple knew where they were going, and have had a few years to play with with how to implement it and test it. In public view.

  • Bill Russo · April 17, 2011 at 11:46 pm

    I seem to remember Lightworks had a “save every keystroke” feature way back in the early ’90s.

  • Ryan P · April 18, 2011 at 3:57 am

    Even more important then the iWork/iLife apps, is iOS itself. That entire OS was designed from scratch to never have a save command.

    And Lion is the “Back to the Mac” ( from iOS ) release.

  • Andy · April 18, 2011 at 5:25 am

    Just curious: I heard the rumor a while back (don’t even remember where) that there could possibly be different installs depending on which OS you’re running. 10.6 or 10.7, which enables Lion specific features and/or technologies accordingly. Could something like this be one of them?

    Is there *anything* that you think might fall into that category for that matter? Aren’t there several new and relevant OS level features and technologies that you couldn’t simply teach 10.6 with a simple incremental update??!

    Could in fact the two release dates being practically the same (wasn’t the potential Lion release date just upped majorly to around June also?) point to this? Marketing-wise it sure would make sense, along the lines of “Works great on 10.6… but if you’re on Lion it’s AWESOME!” A double-whammy-upsell! 😉 (tho the mere thought of a DOUBLE upgrade would fry a lot of “pro” brains)

  • Jon Chappell · April 18, 2011 at 8:41 am

    You can query XML documents through XPath and XQuery. I think the term “queries” in this context is rather vague and doesn’t necessarily mean a database.

  • Admin comment by Philip · April 18, 2011 at 9:36 am

    Simply put No. The current release runs on Snow Leopard as it’s being beta tested on that platform now. To do that all the Lion features (AV Foundation in particular) will need to be bundled in the app package. When it comes to Lion, if there’s a newer version of AV foundation then FCP X will use it rather than the one in the package.

    The “two versions” rumor was simply an interpretatin error by someone who doesn’t understand how mac apps work with frameworks.

    Lion is to be released in “Summer” (June 21 to Sep 20) and FCP X is to be release in June (originally “Spring” which is up to June 20). No relationship to the Lion release at all.

    A different version for Lion would be a Sarbanes Oxley nightmare and wouldn’t be done simply for that reason other than any technical ones.

  • Robert Lawson · April 18, 2011 at 3:47 pm

    About Pinnacle Liquid – I asked an Avid (formerly Pinnacle) employee about that once. He confirmed that a Liquid project was a database so that no “Save” command was necessary, because everything you did was recorded in that database.

    He also told me that Liquid projects became completely unwieldy in long form editing. The database file just got too large.

    I have no personal experience with Liquid, and very little with Final Cut Pro, but I can’t imagine that wouldn’t be a limitation of any hypothetical FCPX database-centric project, sooner or later.

    • Admin comment by Philip · April 18, 2011 at 5:15 pm

      Thanks for the confirmation about Pinnacle/Avid Liquid. I can’t imagine a modern database becoming unwieldy with a large project. Was just confirming that CatDV (server) can handle “hundreds of thousands” of assets in what is (underneath) a mySQL database. I’d expect FCP X to be talking with sqLite or other Db via Core Data but don’t know that for a fact, just that would be the way for a modern OS X app to do it.

      • Graeme Herwig · April 27, 2011 at 3:40 pm

        just to add further to the “always saved” NLE history.

        Both Fast Multimedia’s ‘Purple’ (dv) and their ‘Silver’ (mpeg) NLE Systems had ‘Always Saved’ as standard. this was around 1999/2000 and a few years before Pinnacles buyout of Fast Multimedia.

        I lost track of these systems but i think these Fast Multimedia ‘Purple’ and ‘Silver’ NLE systems were what Pinnacles Liquid systems evolved from. with Pinnacle adding the ‘Liquid’ prefix. to Purple and Silver.

        Fast MM also had an Uncompressed system called ‘Ivory’ (my memory gets sketchy here) and another called ‘Blue’ (not sure if they ever released this one- i think it was finished and released by Pinnacle) Blue promised multi format video editing and export.

        Phil – thanks for whats properly the best commentary / unraveling of the development of FCP – always great to read the comments and discussion too

<<

>>

April 2011
M T W T F S S
« Mar   May »
 123
45678910
11121314151617
18192021222324
252627282930