The present and future of post production business and technology

What is Apple doing with Final Cut Pro?

We were talking a couple of night ago and discussing how various of the NLE developers are dealing with the Carbon/Cocoa transition. But before I get to that a disclaimer and some background.

Disclaimer: I have no inside knowledge. If I did it would almost certainly be under NDA and therefore would not be shared. Everything I post here is based on publicly available knowledge, if not that commonly known. (Depends on how much you care about code and most people don’t.) So, I present data points, interpretation and extrapolation: in plain English, guesswork, but intelligent guesswork! PLEASE DO NOT CONSIDER THESE RAMBLING “RUMORS” OR HAVING ANY INSIDE KNOWLEDGE. THEY DO NOT AND ARE NOT RUMORS.

Final Cut Pro, like most software developed originally for OS 9, is built on a type of code called (for short) Carbon. The Carbon APIs (Application Programming Interface – the building blocks of code) allowed Final Cut Pro, Photoshop, Illustrator, Media Composer and thousands of other applications to make the transition from OS 9 to OS X “reasonably painlessly”. (Meaning, hard but not impossible). Carbon code runs just fine on OS X and is no less efficient in and of itself than the more modern Cocoa code.

So-called Cocoa code is the native language for OS X. It is built almost completely on NeXTstep, which Apple acquired when they acquired NeXT (and Steve Jobs) as a replacement for OS 9. Now, originally Apple said (at the 2006 WWDC) that there would be 64 bit versions of the Carbon APIs. This would have meant that Final Cut Pro, Media Composer, After Effects, Photoshop, Illustrator, et al. would be able to move to 64 bit versions without major rewrite. And so it was good.

Until a year later. At WWDC in July 2007 Apple reversed that decision and said that any application that wants to go to 64 bit would have to be rewritten to Cocoa.  Much gnashing of teeth in the ProApps camp and at Avid and Adobe. Not only can’t they go to 64 bit without rewriting but Final Cut Pro cannot start to use OS X technologies like Grand Central Dispatch and OpenCL until that rewrite is done.

I’m much less familiar with Adobe’s code but the current version of Premiere Pro was ported to OS X in the modern code era and is almost certainly Cocoa where it hits the OS X road. It is highly likely that the majority of the code is in a format that is common to both platforms with mostly interface-specific code for each platform.

That’s also likely with the Media Composer code but I have reason to believe that Avid have been progressively rewriting functional blocks of code from Carbon to Cocoa over the last several releases (since mid 2007 probably)!

Most of the ProApps are already written in Cocoa: Soundtrack Pro, Motion, DVD Studio Pro (when it was based on Spruce not Astate’s code) and Compressor. These are already in a form that makes it relatively easy to move forward to take advantage of modern OS X technologies.

Not so Final Cut Pro.  Now we do know that most of what has been added to Final Cut Pro in recent versions has been written in Cocoa. Apple’s Xcode development tool allows a mixture of code types in the one application. I’m uncertain whether Multicam is written in Cocoa but I’d expect it to be. HDV Log and Capture; Log and Transfer; Share, Master Templates etc are clearly also written in Cocoa. (The main evidence is that the interface is using the “ProApps Kit” interface used in Motion, Soundtrack Pro et al.)

So to the question that started the post: “Are Apple rewriting parts of the code as they go?”  I think the answer is yes.

One really strong piece of evidence is the new Speed Change tools in Final Cut Pro 7. The new interface is ProApps kit, not Final Cut Pro’s interface elements, which by itself suggests new Cocoa code. What is stronger evidence is that speed changes in XML files give different results when imported to Final Cut Pro 6 than they do when imported to Final Cut Pro 7. This is very strong evidence that new code is involved. (The old code would give the same result even with a new interface.)

One would have to extrapolate that the new Marker functions (with their new interface) has also been given new code but that’s much less certain as the Marker interface still shows the original Final Cut Pro interface style with new elements added. (Compare the Speed Change dialog and Marker dialog to see the difference.)

The rewrite to Cocoa, even assuming they don’t make fundamental changes* is very time consuming and a lot of hard work to rewrite and test. That there is evidence in the current release of work already complete strongly suggests that the team is hard at work doing what’s necessary to bring Final Cut Pro into the modern Cocoa OS X code era. But don’t expect to see a converted release any time soon. There’s a lot of work that the QuickTime team has to do to add functionality to the underlying QTKit API (The modern QuickTime API for programmers) that an updated Final Cut Pro needs. Right now there’s no support for QuickTime metadata in QTKit, for example.

* Fundamental Changes. We’ve argued this instead of watching TV as well. Most of Final Cut Pro’s functionality is just fine. There’s not a lot to be gained by totally redesigning and redeveloping the Transition Editor, for example. There are, however, two areas that I think it would behove Apple well to rethink: Media Management and Metadata views. Media Management in Final Cut Pro is now reliable, except for a few edge cases (largely to do with dual system and merged clips). Whether or not to spend a lot of effort (and dollars) to improve it that last little bit for the relatively small customer base that would benefit is a management decision I’m glad I don’t have to make!

I do think they need to do something more flexible with metadata support. Non-tape sources come complete with comprehensive metadata that Apple capture and insert into the media file. This support was added in my all-time favorite Final Cut Pro release – 5.1.2! Unfortunately the Bin interface has limited flexibility. While there are a lot of viewable columns there’s no way to add a column unless you’re the Apple engineer that does that!  Other NLEs are much more flexible. Media Composer will add as many columns for whatever metadata you ask it to display. Not so Final Cut Pro where the only simple way to view QuickTime metadata in a QuickTime file is with my company’s miniME. (Go on, download it. The free demo lets you view all QuickTime metadata in a file and export it to an Excel spreadsheet. Buy it and you can remap the metadata into Final Cut Pro’s columns.)

It takes years to make major transitions in software. QuickTime metadata support came in late 2006. With the advent of Log and Transfer, that support became valuable. So my informed guess is that a future release of Final Cut Pro will allow that metadata to be viewed and used in Final Cut Pro. It’s all there in the file and in any XML export. To me that suggests a foundation for some future construction.

Like I said, nothing more than intelligent guesses. NOT RUMORS. NOT INSIDE INFORMATION. Just me joining dots and I’m bound to be wrong about half of it. I just don’t know which half!







10 responses to “What is Apple doing with Final Cut Pro?”

  1. Phillip,

    You might also want to think about which parts of Final Cut Pro might benefit from the speed increases 64 bit would bring.

    (Not being a major user of FCP I can’t offer an opinion.)

    // Tony

  2. The most useful application I can think of off the top of my head that currently does not already exist in NLEs for the extended metadata would be location, camera movement, face recognition, and transcribed audio once the requisite sensors (GPS/Accelerometer/face recognition engine/voice recognition) are integrated either in the camera hardware or at the ingest phase on the computer.

    There is so much logging time to be saved from never having to type in location, camera movement, name of person in shot ever again.

    1. I just submitted an article for the 4th Supermeet Magazine – out at NAB in April – that deals with exactly that Dustin. How we can use and acquire that metadata and make post easier.


  3. I’m just hoping they fix the underlying inefficiencies with the project file format. Those file sizes can grow to be absurd.

  4. mpheadley

    FCP editors should really watch the demo videos of in development Premiere CS5 in combination with the NVidia cards. Good luck FCP!

    1. The Adobe Mercury engine is indeed awesome… *if* you have one of the four supported graphics cards (just one on OS X). I also doubt that real-time performance is the only criteria for choosing an NLE.


  5. John Miller

    I agree re the metadata, however any 2nd assistant/ production assist/continuity person should always note this info anyway, and the editor gets a hard copy as backup.

    1. If only that were universal John, if only. A film now in production in 2010 was planning to use digital betacam SD for dailies, losing all reference to original media (video and audio). Until I pointed it out, no thought had been put into determining who and how matchback would have been managed. They ultimately decided on digital dailies so metadata could be tracked via Media Composer.


  6. One thing to really look at is how to solve the fundamental fiasco that is Quicktime. I do a lot of work with QT as well as other formats, and never do I have to spend more time fixing problems than with QT – gamma shifts, timecode rounding errors… please Apple, it’s been long enough, fix these problems.

    1. QuickTime has both pluses and minuses compared with other formats. As a developer we’re not seeing the timecode rounding errors and one of our core products (and an unreleased one) are 100% TC based. But gamma has been a problem, so you’ll know if you stay within the proapps family of products you won’t experience gamma shifts anymore. That problem has been fixed to the degree the ProApps Team can. Remember that’s the only code the Pro Apps team actually control. Sadly they don’t control the QT team.