There’s been some chatter today about Final Cut Studio and “64-bit.” Now first, simply saying 64-bit is fairly meaningless. 64-bit applications can refer to 64-bit processing (as in computation) and 64-bit memory space. In audio, it’s even more confusing, as we routinely refer to 64-bit audio signal – which is something that can actually be computed on a 32-bit application running on a 32-bit processor.

One notable example:
Apple Releases New Final Cut Studio, All Apps Still Only 32-Bit [Daring Fireball]

I suspect that what people want when they say they want “64-bit Final Cut” is access to more RAM. If you compare 32-bit to 32-bit, at least, the Mac has a big edge on Windows and Linux, because it can give a full 4GB to each and every running app, provided available memory on the system. But 64-bit memory space, with access to far beyond that, could be fantastic. Both Sony Vegas and Premiere Pro now run on 64-bit Windows, with 64-bit memory addressing meaning you can, for instance, load video previews into RAM. Adobe claims big performance gains on their 64-bit Premiere Pro, too. And with all due respect for the quality of Apple hardware and OS, these apps run on any computer you buy – no vendor lock in, and no refusing to run on certain machines (like my non-Pro MacBook). Final Cut has its own strengths, too, of course. But, then, that’s what competition is for.

So, it seems there isn’t a 64-bit version of Final Cut Studio. It’s too bad: Apple’s got a 64-bit OS and 64-bit hardware. And I do understand the frustration. My guess is that Apple isn’t making an arbitrary decision, however. Their customers may be dependent on plug-ins that could break with the move to 64-bit. Or there may be some APIs on which Final Cut relies that haven’t become 64-bit — or won’t until Snow Leopard. That’s, incidentally, the kind of reason that keeps a lot of Windows and Linux users on the 32-bit versions of the machines. (It’s one reason I think it’s crazy that Microsoft treats 32-bit and 64-bit versions of its OS as separately-authorized licenses, but I digress.) Unfortunately, I can’t get any solid information on the subject (or on Logic), so I’m rather disinclined to speculate beyond that.

I should clarify, as Anton points out in comments — if you want a culprit for the lack of 64-bit, it’s QuickTime. QuickTime X in Snow Leopard promises 64-bit “computation” and I’ve seen a reference to 64-bit memory addressing, so it’s possible both these features will sync with a new release of Final Cut Studio.

One thing I will say is it’s time to stop blaming this issue on “Carbon,” as that’s a misunderstanding of how 64-bit Mac development works. Cocoa development is not automatically 64-bit, and conversely, just because something is 32-bit does not mean it’s “Carbon.” So, as Gruber argues that “I suspect they’re all still using Carbon,” he’s essentially making it up — there’s no real basis for that claim. In fact, if he’s implying that Final Cut is built largelyon Carbon, he’s almost certainly dead wrong — Apple’s internal developers made the move to Cocoa long ago, as it’s something heavily evangelized at Cupertino. I have no doubt that Final Cut is a very modern, heavily-optimized video app. If you’re still not happy with its performance or like an alternative, well, I also have no doubt that building modern, heavily-optimized video software is an immensely difficult task, period. (“Video sucks” is one of my regular adages, alongside “I hate computers.”) I’m not just giving Apple a free pass, either — this is true of what Sony, Avid, Adobe, and the open source community all face, as well.

I’m not entirely sure why this is making people lose sleep at night. If you’ve chosen the Apple toolchain, presumably you’re already reasonably happy with their software. I think it’d be reasonable to assume Apple — as the rest of the industry and even the open source community — is working on 64-bit pro desktop apps. It’s impossible to know when they’ll be done or what the hold up is because Apple doesn’t like to talk about those things. I wouldn’t be at all surprised if Final Cut and Logic see some kind of performance bump synced up with Snow Leopard. Even if they don’t rely on Snow Leopard enhancements per se, an update of some kind in that timeframe seems inevitable. And it wouldn’t be a surprise to see 64-bit then. But if I knew that, I couldn’t tell you — because it’s Apple, right?

  • “I suspect they’re all still using Carbon,” he’s essentially making it up — there’s no real basis for that claim. In fact, if he’s implying that Final Cut is built largelyon Carbon, he’s almost certainly dead wrong….

    Yes and no, Grubers's no idiot when it comes to these things – I would agree that new Apple apps are written in Cocoa but Final Cuts UI is very much locked into very old conventions compared to apps such as Motion, DVD SP & Soundtrack (the last one being only 2 versions old).

    If they had rewritten FCP in Cocoa I think there would be a lot more consistency across all Pro Apps – and any changes to one would follow through to others. As it is these newer apps have similar UI's across Video AND Audio apps – with FCP & Color being the exceptions.

    My feeling is that Apple have pulled an Adobe CS3 upgrade experience, where we all remember Adobes CS3 launch missing Intel nativity (and the switch to Cocoa).

    With FCS3 there's lots of nice bits but no game changers – no 1 step distributed rendering (I don't mean encoding), no 64bit and no cocoa across the board. Which leaves me with more questions –
    Did Apple not want to wait and go with 64bit/Snow Leopard only so not to alienate not only all PPC users but all 1st Gen Core Duo Mac owners too?
    Will the next version be completely rewritten, 64bit only and designed to take full advantage of Snow Leopard and Grand Central?
    I hope so.

  • Warwick Brown

    I would be quite surprised to find Final Cut Pro was now Cocoa based. You have to remember that this is an application that was originally written for pre-X Mac OS. Applications in this category (such as Photoshop) became Carbon as it was far easier to convert an OS 9 application to OS X using Carbon than it was to start fresh with Cocoa.

    Apple may be internally making the move to Cocoa, but it is clearly taking time. Snow Leopard is the first time that the Finder is Cocoa based, and considering the scope of rewriting something like Finder compared to the behemoth that Final Cut is, I'd say it's most likely Final Cut Pro is still Carbon.

    A quick test one can do to verify with some degree of certainty whether an app is Carbon or Cocoa based is to turn on full keyboard UI control interaction (SysPrefs>Keyboard>Shortcuts). In Cocoa apps, tabbing between controls will select everything, including buttons and drop boxes, whereas in Carbon it will be limited to input boxes. Final Cut Pro (6 at least) behaves in the latter way.

    The major reason for why Final Cut would not be Cocoa would be the same reason Photoshop is still Carbon. There has been little to gain from changing to Cocoa. Why waste years re-writing an app from scratch when you can just add features to the one you've already got? It was only with the announcement of no 64-bit Carbon that a clear advantage of Cocoa emerged.

    I suspect a re-write is taking place behind closed doors, but the public release is still 32 bit Carbon.

  • Pingback: Create Digital Motion » What’s New in Final Cut Studio?()

  • Oh, it's very possible that there are still Carbon calls in FCP, don't get me wrong. But it's not as easy to tell, partly because a lot of these apps are written natively without the heavy reliance on the Mac frameworks another app might have. In short, my understanding is, we just don't know. And it's very possible with something like the keyboard shortcut thing that these apps are written with their own custom event handling code for performance reasons (though there, again, I'm just speculating — you can't really know for sure).

    What I've been told by Apple in the past (officially and off the record) is that there is an extraordinary amount of under-the-hood work that's been done on all the pro apps. 64-bit is an additional effort whether you're starting from Carbon or Cocoa. So, really, regardless, I think you should expect another transition to get there.

    And sometimes it just doesn't get prioritized. On Windows, Cakewalk was one of the first 64-bit applications for consumers period — not just music apps — when Microsoft did Windows XP x64. It's taken far longer to get other software that's 64-bit native, and Microsoft shipped a 64-bit-capable OS ages ago.

  • Er, having a 64 bit FCP requires having a fully working 64 bit Quicktime, which no one has now, or knows what the final incarnation is going to be like. As for having a 64 bit OS, they do not currently (10.5.x) have a full 64 bit stack for all of the libraries something like FCP would require. For all you know Peter, once Snow Leopard comes out there may be a point release to 7, which allows it to work with 64 bit QT X and what not. I'd honestly be very surprised however.

    FCP is fine, and this release is similar to Snow Leopard in its mostly tuning things that really need fixing, but are not all one huge giant feature set. Many Editors I know are looking forward to small things like refined markers and better timecode viewing.

    I look forward to it. This is post is really … stretching it thin πŸ˜›

  • Um, Anton — I don't get your criticism. You're saying basically what I was saying. My whole point was that people are running around saying there's no 64-bit Final Cut without a) being clear about why they want it or b) having any sense of what's required technically to get there or c) what may be coming in the future.

    Now, as for "no one knows what the full inarnation is going to be like" of QuickTime X, that's not entirely true. Apple has promised 64-bit memory addressing specifically in QuickTime X. I've already said before that I find it frustrating that Apple is the only OS vendor I know that doesn't really lift NDA on new OS and dev technologies until the day an OS ships. (That's not true to the same degree of any other OS — Windows included.) So I can't go into more detail or ask Apple about that because I'm not allowed. But I'll resist the temptation to go on that rant again, and … oh. Oops. πŸ˜‰

  • All my point was is that 64 bit is a non issue right now.

  • Well, it's an overblown issue in these other cases – that was the point of what I wrote. But it's not a *non-issue* – not when competing video editors are able to take better advantage of your installed memory, especially when those competing video editors run on operating systems that now also run on your Mac.


  • Anton, dude, calm down. That doesn't make it a NON issue, that just means it's the OS vendor's problem. Oh, wait — that'll be, uh, the same company. So, it's a perfectly reasonable issue to bring up, especially when said OS/application vendor doesn't like to tell anyone what it's doing in advance. People are wondering where this is because it's a useful feature, and because Apple themselves have been touting the 64-bit computing and memory capabilities of the OS for some time. So, I think it's reasonable to at least hope they fix the frameworks.

    What would be unreasonable is to ding Apple for not doing 64-bit without explaining why you want it, or to claim this is a "Carbon" issue when that's not entirely accurate. But I didn't do that; I was calling out other people doing that in this story.

    If anything, you would think that Apple would have delivered this functionality first, given their control of the OS, the frameworks, the application, and the hardware. On Windows, where *each* of those belongs to a different entity, and on Linux, where *none* of it belongs to anyone, this particular feature shipped first. Now, there are plenty of other areas in which Linux and Windows are behind – some more broadly essential to people than having terabytes of RAM addressing for video editing. But it just demonstrates this stuff is often way more complicated than people make it out to be.

  • Also, technically speaking, Mac OS X *is* a 64-bit operating system, or I should say an operating system that supports 64-bit architectures, 64-bit memory addressing, and 64-bit computation. Whether every last library on the thing does or not, it's usually the core OS that counts. Now, as you rightfully point out, those other bits do matter to application developers a whole lot — hence the hold-up. But I've been pleasantly surprised by the pace on Windows and Linux. I'm still running 32-bit across the board, but 64-bit application development for multimedia is progressing far faster than I would have expected, especially given the dark prognostications early on in the XP x64 days.

  • Peter, its 64 bit capable in 10.5.x for non UI applications. You know this. This is retarded, its such a non issue. If you want to run a 64 bit app in OS X under 10.5 you have to write a background application that is 64 bit with a 32 bit front end.

    This is not even worth DISCUSSING. Im not angry or upset, im just making my points CLEAR. You CANNOT DO THIS TODAY on OS X. Thus, 10.6 and a full 64 bit stack, everywhere, should you want it. How these libraries work and what has changed no one knows. It seems pretty clear even the QT team is uncertain what codecs will and will not be supported for 10.6 under at 64 bit QTKit. Expecting a complete re-write of an app like this to be magically 64 bit compliant on a OS that does not support what that would require (10.5), or to magically work on an OS that is not out yet… See where I'm going with this?

  • I see where you're going, and I agree.


    If it were anyone other than Apple, we might have some kind of road map. We might not be stuck with idle speculation – which I agree is a waste of time. You might not have to pay a developer fee and sign an NDA and still not no what's going on.

    In my fantasy world, Apple starts conveying some of this information to its customers in advance of when it happens so those customers can *act on that information*. Software like Final Cut Studio often involves large purchase orders. It'd be helpful to know, for instance, if there were going to be significant performance improvements coinciding with an upcoming OS that had significant library stack rewrites.

  • So to summarize, in La La land, Apple is a different company everything is great πŸ˜›

  • Yeah, there are actually no operating systems, either, just a magical gnome that lives inside your computer that makes everything work. Not to be confused with – less magical.

  • Warwick Brown

    @vade, I don't believe you are correct about OS X not allowing 64-bit front end applications.

    In 10.4, this was indeed the case, as only the Darwin/UNIX layer was 64-bit compatible. In 10.5, 64 bit compatibility was taken all the way up through the OS's layers to the Cocoa GUI API.

    Snow Leopard's 64-bit refers not the the availablity of 64 bit development tools, as they already it exist in Leopard. It refers to the fact that many of Apple's built-in applications are now 64 bit.

    You must remember that Photoshop Lightroom is 64 bit. This is possible because it is a new application and was written for Cocoa which now supports 64 bit. Photoshop, on the other hand, does not support it because it is Carbon and plans for 64 bit Carbon were scrapped.

    Peter, I am not entirely fussed whether or not it's 64 bit, however I think being able to address a larger memory space will have definite advantages. I still believe the lack of support will be due to FCP being a Carbon app and suspect that alongside the development of this release, a complete re-write is underway (much like Photoshop CS5) to Cocoa so it can take advantage of 64 bit, and also the new OpenCL and Grand Central Dispatch technologies.

  • The whole stack of included libraries with 10.5 is not 64 bit, so, yea, you can write a Cocoa 64 bit app, but not a QT App, or a xxx App or yyy app. 10.6, "everything" is fully 64 bit capable, not just certain libraries, as was the case with 10.4 and 10.5.

    However, the APis for these libraries are vastly different in 10.6 betas, so its not even clear if you can indeed do what needs to be done for FCP with QT X as it stands now, in the betas. Of course, this can (and most likely will change).

    But yes, technically, you can write a 64 bit cocoa app in 10.5. Just not FCP, which is what we are talking about. I should have been more clear in what I was saying, as my comment is not correct strictly speaking πŸ™‚ Thanks for pointing that out πŸ™‚

  • Well, right; this has wound up being an interesting thread as I had lost track of what exactly was synced with which OS release. As I recall, though, adding the 64-bit UI was one of the advances in Leopard, and even some 64-bit features were possible in Tiger, just not the UI (?) (I know it's likewise possible to write a *Java* app that's 64-bit in Tiger, though I don't know if you then lose Swing and Quartz… haven't looked into it.)

    But yeah, without QuickTime it'd be a less interesting version of Final Cut. It would run *really* fast, of course, not having to do anything with video. πŸ˜‰

    I believe a 32-bit Cocoa app still needs to be rewritten, though, yes? And of course, QTKit is a Cocoa library, not a Carbon library, but still doesn't support 64-bit.

  • Look, morons. People want to take advantage of more memory. Faster editing, more features, etc… 64bit allows this. It's a huge issue. I know one person already who's switching to premiere pro on PC because it's faster and has access to more memory than Final Cut. So you're an idiot if you say this is a non-issue.