Category: Technology

With the apparent demise of Shake – really nothing real now, as it seems to have been withdrawn from sale – Apple appears to be redirecting enquires to the Final Cut Studio 3 pages, suggesting that they consider Motion a substitute for Shake. I hope there’s something else coming (“Phenomenal” anyone?) because Motion is not a substitute.

Now, before I get into the reasons why they’re not interchangeable, let me say that it might make perfect business sense to drop Shake and not replace it. Shake, when Apple purchased it, had about 200 customers. That number has obviously grown dramatically but I’d be surprised if there were 10,000 true users: people who use Shake as the high-end compositing tool it was designed to be. It was also obvious that Shake, as it was, wasn’t going to be able to move forward in any serious way: no way to hook into GPU power or other such lush goodness.

Creating a replacement from scratch – all new, modern code – is an expensive operation. For a company like Apple, probably in the tens of millions of dollars to not only create the application but to test it internally (the Motion team, at time of launch, had as many QA people as software engineers), put the marketing plan into practice, run launch events, seminars, create training resources, etc. At Apple’s level, software is an expensive business.

The market for high end compositing software is small, and in the time Shake hasn’t been developed competitors have been significantly upgraded and taken market share from Shake. Maybe the decision was made to simply take what they could from Shake and roll it into Motion.

But Motion is not now, nor ever will be, a replacement for Shake. Motion is a great motion graphics tool with compositing capability. Shake is a compositing tool with some motion graphics capability. You see the problem.

Motion is an excellent motion graphics tool for video editors. It is designed to make it relatively easy for non-experts to create some fabulous looking motion graphics. Shake, OTOH, was for those individuals who were trying to track a head  shot against green screen onto a body while putting the whole body into a scene generated in 3D while adding other 3D characters.

This would be a nightmare to composite in Motion, because it’s not what Motion was designed for.

So, while it makes perfect sense to kill Shake – it was old and needed updating, and maybe updating doesn’t make economic or marketing sense – it doesn’t make sense to pretend that Motion is a suitable replacement.

I suspect that the original purchase of Shake was more for the marketing benefit of being associated with Tentpole movies rather than the income from software sales. Apple doesn’t need that so much anymore (and that’s a good thing).

I’d still like to see what the Nothing Real team would do recreating the application from the ground up with modern technologies, but I suspect Shake will never be anything real in the future.

Since the launch of ProRes 422 in Final Cut Pro 6, I’ve been vocally disappointed that Apple didn’t choose to license Avid’s DNxHD family of codecs instead of developing their own competing (and almost identical) ProRes 422. Right down to the data rates used, the two codec families are very similar.

Except DNxHD is truly cross platform including *creating* files on Windows. Apple might not want to acknowledge it but the best high end compositing apps (Nuke et al.) are Windows and many of the highest end 3D apps are Windows only. That’s the world Apple’s customers live in and not having a way to create ProRes 422 on Windows is still a failing of that codec family. DNxHD codecs can carry alpha channels in all versions. Plus, if Apple had adopted DNxHD then media would be (sort of) compatible between Final Cut Pro and Media Composer. (A rewrap from MXF to QuickTime would be required, or the use of RayTools to read MXF natively into Final Cut Pro.)

But with the release of Final Cut Pro 7 and the new ProRes 4444 codec, I can see why Apple wanted to “do their own thing” as it were. They get to control the future of the codec family without involving third parties.

There’s no DNxHD 444 codec. There is now a ProRes 4444 codec and there is now alpha channel support for those who want it. (Admittedly I’d like to see alpha channel support in the 220 and 140 Mbit versions as well, but perhaps I shouldn’t be greedy.)

While it only duplicated DNxHD functionality (and really the new 45 Mbit Offline codec in ProRes duplicates the similar DNxHD 36 codec) it didn’t make sense to have competing offerings.

Giving us more than DNxHD does, makes up for the duplication.

But please, Apple, give us a way to create those files on Windows. I’m no Windows fan but this is the real world and Windows exists in media creation.

In the comments on my article on “Why no ExpressCard 24 slot in the new MacBook Pro” Andreas asked about Final Cut Studio and Snow Leopard and I briefly responded there. Larry Jordan responded on his blog (Andreas asking him the same question) but not in any detail. Neither Larry nor I are programmers, but  I direct programmers every day – both OS X software and Web applications – so I do know a little. Plus I’ve tracked the technology development for FCP from version 1 onward – every change from OS 9 to OS X CFM, to OS X Mach-O to a hybrid application.

So, let’s see if I can manage a little clarity even if it’s only based on observation and deduction. As I said in the brief response, I have no clue what development Apple are doing and whether or not this is at all accurate. No doubt there will be engineers at Apple laughing at my naivety!

Carbon was the technology that Apple developed to let OS 9 applications run on OS X. It’s a set of programming interfaces (APIs) that individual applications call. There’s absolutely nothing wrong with Carbon, except that it can’t take advantage of any of the modern features of OS X – particularly those coming in Snow Leopard, nor can it run in 64 bit.

Cocoa is a different set of APIs, heavily drawn from NeXTSTEP – the NeXT operating system (Apple acquired NeXT in 1996). It is the preferred method for programming for OS X. In fact Apple have been pretty clear to its developers that, long term, Carbon will give way to Cocoa. They are encouraging all developers to get their code to “pure cocoa”.

When it looked like Apple were going to continue Carbon development with 64 bit APIs, as announced at the WWDC in 2006, there was really little incentive for Apple to spend the very many millions of dollars it will cost to rewrite FCP’s Carbon parts as Cocoa – to just get to where it is now. 64 bit Carbon was also Adobe’s preferred path for its older applications (Photoshop, Illustrator and After Effects). With 64 bit Carbon coming, Adobe could get 64 bit support without a major rewrite.

But when, at WWDC in 2007, Apple changed the rules and said, “No 64 bit Carbon”, any high-performance application had to think seriously about rewriting to Cocoa, at least long term.

We know, from public announcements, that Adobe had to delay 64 bit support for the named applications until CS 5 on OS X because of the time it takes to move applications to Cocoa and therefore 64 bit support.

All new features in FCP, since FCP 5 onward, have been written in Cocoa – HDV Log and Capture, Log and Transfer, Multicam, FXplug (that I know of) are all Cocoa. OS X lets programmers mix and match programming languages with ease. My guess is that Apple, like Adobe, would have continued with a hybrid approach with Final Cut Pro if the 64 bit Carbon APIs were going to be available. When they were not, the Pro Apps team, like Adobe, would have to have started porting their application to Cocoa. CS4 showed none of that progress, being released less than 2 years after the ’07 WWDC announcement.

Most of the FC Studio applications are new enough to have been written in Cocoa – the second revision of DVD Studio Pro (Spruce, not the Astarte-based DVD SP 1); Motion, LiveType, Soundtrack Pro and Compressor are all pure Cocoa applications and can (relatively) easily take advantage of 64 bit and/or Snow Leopard features like Grand Central Dispatch. I say “relatively” because there is still work to be done, that generally can’t start until Snow Leopard’s features are locked (i.e. WWDC 2009).

No responsible programmer is going to attempt to write for a new OS until the OS is locked and finished. So, theoretically, the engineers working on those applications could start NOW to work on Snow Leopard features, ready for a release in a year or two.

I can’t imagine that even the Cocoa-based Studio products will be taking advantage of any Snow Leopard features this time round – the timing is just all wrong. And they’re already Cocoa.

FCP, starting life at Macromedia as a cross-platform OS 9/Windows application, has most of the core written in Carbon. My (educated) guess is that it will take 2-3 years to rewrite all that code to Cocoa. I doubt they started that before WWDC 2007, as until then there was little incentive to invest many millions of dollars in a Cocoa rewrite. (Remember this is before the announcement of Snow Leopard, Grand Central Dispatch and OpenCL too.) Those features do provide an additional incentive to get FCP to “pure cocoa” (I estimate $10-15 million will be required to write, test, test, and I hope test what will effectively be v1 code again).

Apple will no doubt do that because the Final Cut Studio is highly profitable for the company from software sales only. (You don’t need to get too much from 1.25 million customers to make a viable business, even without taking into account any hardware sales, which don’t benefit the Pro Apps team at all.)

However, wanting to do it and having the time to do it are different things. They didn’t start (most probably) until after WWDC 2007 when they, and the Adobe teams, learnt that 64 Carbon wasn’t going to happen. Allow two to three  years to finish that job, before they can start to think about Snow-Leopard feature optimizations.

Pretty much every release of FCP requires the latest OS (the exceptions being FCP 3 which was for OS X and OS 9 both, and FCS 2 which is Leopard OSX 10.5 or Tiger OS X 10.4.11) and the latest QuickTime. So, I think that Studio 3 will, on the balance of probability, require Snow Leopard. Snow Leopard has no problem running 32 bit Cocoa applications at the same speed they always ran. As Snow Leopard has no PPC version, it could mean that FCS 3 may be not supported on PPC, we’ll have to wait for Apple to let us know. (FWIW, Adobe’s Production Premium CS4 is Intel only; Avid’s 3.x releases are Intel only, by way of reference.)

However, absolutely do not even think about running FCS 2 on anything newer than Leopard. In fact NEVER run FCP on any version of the OS or QT other than the ones that were directly supported. To do so is going to cause you problems, pain and regret. Old versions are never tested on the new OS and QT so there’s no reasonable expectation that they will run on a newer OS.

So, whether or not FCP 6 will run on Snow Leopard or not is irrelevant. Only an idiot would attempt it, and none of my readers are that stupid, right? Bank on an FCS upgrade to run the studio on Snow Leopard because it’s the only way to guarantee you’ll still be in business with an operating NLE after the upgrade.

Based on all that, the timing of Snow Leopard etc., it’s not really reasonable to expect that there will be Snow Leopard features in the next release, but we won’t know until Apple releases them. Until then, I guess we can all dream! 🙂