Over dinner last night we were discussing the history of Final Cut Pro, various WWDC announcements and it suddenly struck me that Final Cut Pro 7 was originally going to be a 64 bit release, until Apple pulled the rug from under the Final Cut Pro team (as well as other developers, specifically Adobe).
For a little background you could read John Gruber’s The $64,000 Question but the salient points is that Apple announced 64 bit Carbon support at WWDC 2006 (and withdrew it at WWDC 2007). Like Adobe I presume that the Final Cut Pro team decided that would be the simplest way of moving Final Cut Pro forward and chose to use it.
Except when it was pulled a year later, getting to 64 bit became a major rewrite as most of Final Cut Pro is written in Carbon.
If we consider that Final Cut Pro is on roughly 2 year release cycles up until now (which it has been), a 2009 Final Cut Pro 7 release would have had to start planning well before the Final Cut Pro 6 release. The general way software is developed is that features are allocated to a release and then it’s decided 9-12 months before the release what is actually going to make it or not. This is generally before internal QA testing and external beta testing; usually before the version is finished.
That would suggest that the major features of Final Cut Pro 7 would have been decided sometime in mid 2006: around the time 64 bit Carbon was being announced. Given that would – if 64 bit Carbon had happened – meant that a 64 bit Final Cut Pro was a recompile (and tidy up) away, why wouldn’t you plan that instead of a major rewrite. While significant work, it would be nothing like a complete Cocoa rewrite.
Then came WWDC 2007 and no 64 bit Carbon. Features for the Final Cut Pro 7 release would have been pretty much locked by then when 64 bit Carbon was called off. That’s also why there were no 64 bit Cocoa releases in Adobe CS4 either! (I believe Adobe were able to get to a 64 bit Cocoa release faster is because most of their code is cross platform and the Cocoa-ness of the application is largely in the interface layer. Plus Adobe aren’t dependent on QuickTime at the core.)
Too late for Final Cut Pro 7 but I think that late 2007 was when the Pro Apps group decided that the only way Final Cut Pro would be able to follow the company mandate that all Apple software be 64 bit would be to rewrite the whole application. And if you’re going to do that, why not rethink it as well. Most Apple software has already switched to 64 bit, except where there are significant dependencies on QuickTime! Â (See iLife 11 is still 32 bit.)
Â
Comments
22 responses to “So Final Cut Pro 7 was to be the 64 bit release?”
God …i am sooo done with waiting for this slow, bug laden tool I love and hate on a daily basis to EVER be upgraded. I feel we have now spent years just reading about upgrades while we watch spinning render and other lollipops and freezes.
Maybe thats all that will ever be released – talk about updates, – but no actual new code.
Remembering that if Final Cut Pro was on it’s normal update cycle, we would not have seen another release until mid 2011. That’s the NORMAL expectation.
In the meantime, why not check out Premiere Pro or Media Composer?
Philip
I have never loved the ADVID UI and how unmac friendly they are ( versioning etc – ESPN guy next door uses it and gets caught a lot ‘ No actually you can’t do that OS update…we are not there yet) ), Premiere doesn’t have the toolset, I tried and LOVE Smoke -but its more for later stages – not as timeline friendly – and at 15 grand….
We WILL at some point move to Smoke here i think in some combo with FCP if Apple does as all trends are pointing – which is to de-Pro FCP.
Thanks Philip.
FWIW, I do not see Apple “de pro’ing” FCP. I’ve debunked rumors to that effect in earlier articles (around the AppleInsider rumor in May 10)
I read your debunking and am hopeful you are correct but Quicktime X etc., makes one a ‘bit ‘ skeptical.
I feel Smoke, CS5 etc., are akin to what inDesign did to Quark.
Art, nice anology. Because Quark rested on its laurels with XPress for way too long- as is Adobe.
Even understanding the premise of this article to be true, Apple coders were going to take the easy way out to recode one of their “star” pro applications. Then that easy way out was removed and they’re forced to do what they should have been doing from the beginning.
It’s not like FCS coders, or QuickTime coders, didn’t know 64-bit computing was coming. They’ve really just been so preoccupied with all the “i” stuff that makes gobs of money that they had no real incentive to put serious manpower behind an aggressive timeline to bring powerful new tools to the content creators (like Apple used to do in decades gone by).
correct that to say “-as did Apple”
And now with Xserve and therefore XSAN, Final Cut Server and OSX Server as an enterprise product effectively reaching EOL by 31 January 2011 a new Final Cut version – 64 bit or not – seems not to matter that much.
At least Autodesk and Avid are still putting out product that will work for robust large scale workflows. I guess our choice of craft edit application just got narrower again. We were never that big a market on paper anyway. I just hope FCP does not become a corpse too quickly.
Hw do you draw the connection between a hardware item that wasn’t selling well, to software items that are selling very well? That’s just plain chicken little talk “the sky is falling, the sky is falling”.
Avid arent’ anywhere near close to 64 bit support. It’s probably years away. Steve Jobs is repeatedly on record that they are actively developing FCP and that we’ll like the results.
Just to re-iterate. On the normal release cycle FCP 8 would not be expected before July 2011, so no-one’s “late” until then.
Atually Anthony, they did know it was coming but it was supposed to support 64 bit Carbon for both FCP and QuickTime. Apple announced that at WWDC 2006 and recinded a year later, after FCP 7 was locked off, leaving them without their keynote feature for FCP
And where do you think the whole new foundation for QuickTime is coming from? That’s right, all that work done in iOS on AVFoundation
Exactly. People conveniently forget the FCP 2-year upgrade cycle, and say Apple is abandoning pro apps.
NAB 2005 – Final Cut Studio 1
NAB 2007 – Final Cut Studio 2 [24 months]
July 2009 – Final Cut Studio 3 [28 month]
Another 28 months would put us at November 2011. After that let’s start counting the months.
To add some fuel to the fire- Here’s a link to a classic Jobs response to a question about FCS.
http://www.emailsfromstevejobs.com/2010/10/26/64-bit-version-of-final-cut-studio-stay-tuned-and-buckle-up/
The short version is the guy asks when FSC will be updated and given the ability to fully utilize the hardware [64bit]. Steve’s response,
“Stay tuned and buckle up.”
I guess my only question would be IF FCS wasn’t going to appear until 2011, would Steve, or ANYONE at Apple be saying anything about it at this point?
Well, the release won’t be unti 2012 because of the need to overhaul QT first (ie 10.7) but what really did Steve Jobs say? nothing truly parsable other than yes, Apple are still working on FCP and expect it to be great when it’s done. But that’s what I expected before he said it.
Overhauling QT will most likely mean making it a better content delivery system for mobile devices.
The obsoleted piece of hardware in question (Xserve) represents Apple’s yesterday commitment to enterprise network environments.
There is no FCP upgrade cycle.
Time based media edit environments depend on robust network support. Otherwise they become hobby platforms like Adobe Premiere. At least we got a real codec from Apple in the peerless ProRes.
Chris, that part of “QT” was done in iOS version 1. What’s been added is capture, output, authoring, etc.
If your contention is true about QT then why does AVFoundation on iOS support WAV or BWAV, which won’t play on an iDevice at all
Dropping a product that wasn’t selling well (the Mini Sever is outselling Xserve before the announcement) does mean that at tiny % of Apple’s user base will be pissed off. An even tinier percent of their 1.3 million Pro Apps users will be affected. It’s a non-issue.
There has been a consistent FCS upgrade cycle over the last 6-7 years, which you’ll discover if you bothered to do research instead of shooting from the hip.
Network support for time based media is an issue for less than 10% of that 1.3 million person customer base. Education, Military and Corporate users of FCS outnumber media producers substantially.
AVFoundation on IOS supports WAV – not so sure about BWAV because of that pesky timecode – because there is no solid Apple codec for uncompressed audio which will still be necessary for delivering AAC content on iTunes. That would be via music industry mandate given ProTools and its continued dominance in professional audio production.
I’m sure you’re right – most of the 1.3 million FCP users will not notice the difference.
There was an FCP upgrade cycle.
In mobile centric 2010 Apple and beyond there is no FCP upgrade cycle.
Education and military users will dry up quickly without a network strategy.
I guess broadcast and film – that tiny percent of FCP users with irritatingly high profiles will be jumping ship as we speak.
Its a pity because XML was such a great asset to time based media systems.
And your support for all this? I base everything on solid research so if your next post doesn’t reveal some support, I guess it won’t be posted. People who come here to argue for the sake of arguing are not welcome.
But if you have solid information or well-reserched opinion, please post again. In the meantime:
AVFileTypeWAVE
UTI for the QuickTime movie file format.
The value of this UTI is com.microsoft.waveform-audio. Files are identified with the .wav, .wave, and .bwf extensions.
Available in iOS 4.0 and later.
Declared in AVMediaFormat.h.
And no iOS device currently shipping supports WAV playback. Your starting point is nonsensical and not supported by any evidence.
Philip
I wish I could base everything I have said on research rather than surmise.
What research I have done is based on supporting and training in Final Cut Studio 3 and Final Cut Server 1.5 and having to field questions about network management in workflows.
I found this news about Xserve to be very upsetting for these reasons. Broadcasters technical departments tend to favour end to end solutions from one manufacturer.
I wasn’t trying for nonsense on my last post but looking at it I think rant won – at least about XML and BWAV. Time code in the BWAV header is supported in AVFoundation as it supports version 1 of BWAV.
My wish list for FCP is probably different to most users. I routinely point out and demonstrate the strengths of FCP, Motion, Soundtrack Pro and Color especially for interoperability.
I want FCP to have the surety of a unique file identifier laminated into the back end of it and believe this would easily be possible with Lion and technology already owned by Apple in Final Cut Server.
Looking at the massively successful evolution of Logic which I also support makes me hope that the same streamlining and UI development approach will be evident in future versions of FCP.
In your opinion – not talking upgrade cycles – given the possibly wicked problems confronting Apple in cloud management – what do you think the new FCP will look like?
“I want FCP to have the surety of a unique file identifier laminated into the back end of it”
You’ve got it. Apple have been doing that in non-tape media files since 5.1.2 but we have to wait for the rest of FCP to be rewritten to access it in the FCP interface. We use it all the time in our applications.
As to what I think the new version of FCP will look like, I have no idea. The ideas I have are outlined in “What should Apple do with Final Cut Pro“. Because they were hiring interface designers some months back for Pro Apps, and because the OS X interfaces are going toward scalable graphics, I think it will have a new look and feel. I think inter-application communication will improve to be more seamless – i’d prefer that over any attempt to integrate all the apps which would be a coding disaster (you could never QA the combined application in time for a release).
How different it will look and feel? I have zero data, so take that into account, but the need to make a big splash when they do release suggests they’ll go all out with a rewrite.
And if the next release isn’t all that it should be, I’ll be the first to call them out. Our product range is diversifying: prEdit already supports Premiere Pro as an option for continuing to finish the results; we have a product in planning that will be Premiere Pro only and fill a really nice gap in Adobe’s workflow and we’re actively looking to Windows versions of appropriate products to better serve the Premiere Pro market.
And, as Larry Jordan and I have been consistently saying: if it’s working now, where’t the problem. If it’s not working for you now (whatever “it” is) then change. Change is the only constant.
…and now this [again unconfirmed] response from Jobs to postproduction consultant Dustyn Gobler, who makes a good, reasoned case for a more open software roadmap for the Pro Apps, which may be why he got an email reply.
“A great release of Final Cut is coming early next year.”
full initial email here:
http://www.dustyngobler.com/2010/10/03/email-to-steve/
Two comments in two weeks from Jobs about FCS? If it is indeed coming in the first half of next year? How do we reconcile this with all the work that needs to be done? Another minor release? Code sharing between development teams?
Interesting nonetheless…
I don’t trust that S. Jobs is really saying anything. Dustyn told me about that email weeks before he published it. If it is next year, it can’t be the release we want it to be so i think it would hurt rather than help, but all we can do is wait. What I find really, really odd about “early 2011” projections: by normal release cycles FCS wouldn’t be *due* until July 2011 at the earliest. So early 2011 really doesn’t make sense from a historic perspective and from a “work needing to be done” perspective. Maybe Jobs is just “ahead” in his mind and it’s already 2011 there!
Code sharing is already happening – FXplug is common to Motion and FCP; Share is common to FCP, Compressor (and Motion?). What we don’t want is a combined application that would be impossible to QA.
I have to reason to doubt that the whole works is going to take longer than Q1 2011 to complete properly. So this is definitely a bit of a conundrum.
I can’t imagine it would make sense to put out a point release that would then be fully realized post-Lion.