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!
