The present and future of post production business and technology

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!

You can get a great deal on the AVP Conference for either the whole conference or any single days, by using my discount code: BIGBRAIN when you register.

I’m talking about the Association of Video Professionals Conference Jan 28-30 at the Radisson Hotel, 6225 W. Century Bld, Los Angeles (just near LAX). This year the conference has some of the best trainers in the industry, including myself, Larry Jordan, Frank Rohmer, Mark Spencer, and Bruce Nazarian.

My session, on Thursday 28th is:  Awesome Titling

How to use all the Titling tools available in Final Cut Studio to create Awesome Titles: choose the right font; better typgraphic design; when to use Calligraphy, Motion or LiveType; and animating fonts and glyphs.   Be prepared to experiment, be inspired and be exposed to new possibilities with titles in the Final Cut Studio ecosystem.

Register and use my discount code BIGBRAIN and you’ll get a 10% discount on the full conference or any single day. That’s $20 off a day and $50 off the three day Conference package. But wait there’s more! Anyone that signs up for the conference using my promo code will also receive a free one year Gold Listing on the FindAVideoProfessional.com site (a $149 value).

It’s going to be a great conference. Come along if you want to learn how to make awesome titles and I’ll see you there.

In Apple’s latest release of Logic 9.1, Apple have turned on 64 bit support. Now, I’m not privvy to the internal workings of the Logic code – I don’t even own a copy as I’m not a musician or post-audio guy – it is my understanding that 64 bit support requires the App to be written in Cocoa, the more modern of the underlying coding languages for OS X.

Logic was originally released on OS 9 and Windows by eMagic, long before the advent of OS X. (Apple purchased eMagic in mid 2002, less than a year after the first release of OS X 10.0, and Logic was well established before that.) Logic was therefore almost certainly written in the older language and used Carbon (the older language) for OS X compatibility.

As I’ve written before Apple initially announced that Carbon APIs (Programming interfaces) were going to be released in 64 bit; and then at WWDC 2007 announced that the Carbon APIs were NOT going to 64 bit after all. Basically meaning that, if you want 64 bit support (and you do with RAM hungry applications) then you have to rewrite to Cocoa.

This release of Logic would suggest that work has been complete on making Logic a Cocoa application supporting 64 bit.

That is good news because Apple have another piece of Carbon-heavy “legacy” code that they need to rewrite to Cocoa if it’s to go to 64 bit. That application is Final Cut Pro. The action on Logic is another data point that Apple is very keen to get its applications to 64 bit as soon as possible. Of course, the Final Cut Pro team are also dependent on QuickTime to also support a 64 bit Cocoa API through the QTkit framework.

Right now, the QTkit Framework lacks support for QT features that Final Cut Pro needs: like the ability to read and write QT Metadata through QTkit. (This is currently handled by the older “deprecated” C API from the Carbon days. A deprecated Framework can still be used but Apple are giving notice that you shouldn’t use it. Unfortunately, there’s no current alternative to the C API for that functionality.) So, it’s not as easy for the FCP engineers as it might have been for Logic because this example is only one place where the more modern API does not yet support essential functionality FCP needs.

Still, I’m encouraged by the Logic announcement.

Of course, I don’t have any direct link into the mind of Grant Petty, founder of Blackmagic Design and don’t know more about the purchase of daVinci other than what Grant posted, but it’s such an interesting purchase that I can’t help but comment and guess.

Like so many of the industry’s giants of old, daVinci was losing money in the face of lower priced competition (Apple Color) and a reliance on mostly-obsolete 2K-limited hardware. On the other hand, Resolve is software only and resolution independent running on a cluster of Linux machines connected with Infiniband high speed data interconnect. daVinci also have Revival, although I don’t know anything about what advantages it brings.

Clearly, Grant thinks that the company has not been making the most of its opportunities and more focus on marketing and product development will once-again bring the daVinci brand to prominance. (Assuming it ever lost it.)

However, I don’t expect we’ll see Blackmagic Design suddenly want to start competing with Apple Color. I don’t think that’s the market and Grant himself seems to rule out that direction:

DaVinci Resolve is unique because it uses multiple linux computers linked together with InfiniBand connections and multiple GPU cards so you get the real time performance advantage it has. I donʼt think that can be lowered in price much, however over the next few years as technology advances this might happen a little. However, DaVinci is different to a DeckLink card because itʼs a high performance computing based tool. Our focus will really be on adding more features. Thatʼs what we want, and I guess others would too.

Possibly, some time in the future, a network of multiple Linux machines might be replaced by optimized code on some future 8+core Mac with awesome graphics card and an application written with Grand Central Dispatch and  OpenCL in mind. But don’t hold your breath! Combined CPU+GPU power has to increase a lot to replace multiple machines and the market is not that big.

I think the move will allow daVinci to continue developing their modern products and repositioning the company (to be operated independently of BMD) for the mid-size post house: those that have become dissatisfied with Apple Color but who would not have purchased a full daVinci hardware/software package. If the price could be, say $60K instead of $300K (or more) then that has a really good chance of reviving the brand and – in that inevitable trend – make higher quality available at lower price. That has always been Grant Petty’s goal, so it seems this is consistent.

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.

I was prepared for a “small” release this time round, as I assumed that the Pro Apps Team would be working hard to convert to Cocoa and would have to release a smaller “interim” release, but Final Cut Pro 7 is definitely more than I was expecting.

Having iChat Theater built-in means no more workaround with remote collaboration using two Macs! It also suggests the Pro Apps folk “get” that remote collaboration is booming and they know they need to adapt to that world.

Likewise the new publishing palette is going to be great for a lot of editors who need to routinely provide progress updates and deliver them on the web. That it runs in the background while you continue working is even better. You could have saved a reference movie and sent that to Compressor and added an upload action to the preset, but this is just so much simpler, and gives direct access to the most popular sharing sites, and Mobile Me!  MobileMe might be the best choice for many editors – files can be private and certainly not as public as YouTube!

My all-out favorite features, while a small one, is that Markers in a Sequence now move with the Sequence as clips are inserted or deleted. Colored Markers are great and I’ll use them a lot to identify a type of marker. For example, one color could mean “more work needed here” another color would be a locator just you jump quickly to part of the Sequence, and so on.

The technologist in me is very impressed with the new ProRes codecs. Those that work at the high end will love the ProRes 4444 codecs (and those that want an alpha channel will use it anyway). The Proxy version at 36 Mbit/sec parallels Avid’s own DNxHD offline codec and Apple needed something similar for HD offline. The most interesting codec is, however, the 100 Mbit LT version.

Clearly aimed at acquisition I expect we’ll see camcorders and other devices, like maybe the Ki Pro, supporting this data rate, which is co-incidentally the same as AVC-I at its highest setting. AVC-I up against ProRes 422 LT would be very, very similar in quality, both 4:2:2 and 10 bit and using similar compression strategies. It would be a perfect data rate for the Ki Pro if AJA want to support it. (I can’t help but wonder if the last-minute-delay of the Ki Pro wasn’t to wait for this announcement, but I’m just guessing.)

The Pro Apps team have thrown a “sop” at those who want Blu-ray authoring with the ability to create a Blu-ray compatible H.264/AVC file in Compressor that can be burnt to Blu-ray or standard DVD media. Nothing that Toast 10 hasn’t been able to do for some time now but nice to have it included in the lower-cost Final Cut Studio.

Many have interpreted the inclusion of this feature as an indication that Apple are going to get “more serious” about Blu-ray, but I’m not sure. I think it indicates the opposite. If there was going to be a big Blu-ray push the these features would be added to DVD SP, which received almost no update in this version. I think we’ve got Apple’s “solution” for Blu-ray in Final Cut Studio. Who know, only the future (and probably a Product Manger at Apple) will tell. (The PM won’t ever tell, that’s for sure!)

As to the loss of LiveType. It was probably inevitable as it was increasingly obvious that Motion was taking on many of the roles previously done by LiveType. By adding in the LiveType glyph animation features to Motion (adopted directly from LiveType) most of the functionality is now in Motion. My only concern is whether Motion now recolors LiveFonts correctly (i.e. the way LiveType did). I’ll test as soon as I have a copy in hand.

Finally, the price. Who can complain about Final Cut Studio being the same prices now as Final Cut Pro was alone for the first couple of generations.

Certainly, on the surface, it’s a good release.

On the timing – I notice that all Pro Apps products – Studio, Server and Logic (Pro Music) all came out together for the first time. Does it mean anything? It’s Apple, who knows and I’d rather not drive myself crazy trying to second guess them!

We’ve been working with a few people previewing, and getting feedback on, a new addition to our First Cuts assisted editing tool – basically checking some areas of Final Cut Pro that I haven’t explored for years and I had the most interesting conversation with Jerry Hofman.

Before I get to that though, let me ask (beg) for feedback on any of our software products. We want to keep making them better and love feedback, feature requests and especially problems. We respond quickly – this particular feature request was received on Friday 26th, discussed briefly during a Hollywood Bowl concert on Saturday night and was a preliminary feature by Wednesday!

Anyhow, in discussing this particular tool with Jerry (you’ll find out what it is soon enough!) I asked how much metadata from RED is imported to Final Cut Pro via Log and Transfer. Jerry, who uses RED a whole lot more than me (i.e. he uses it!) said “not very much”, which pretty much matched my understanding working with a whole bunch of RED clips with Sync-N-Link and never seen any of the color temperature, date or other information that’s in the RED metadata.

In sharing this conversation with my smart partner, and our main code writer, Greg Clarke, he commented “Oh, I do think Mr Hofman is mistaken!” (or words to that effect). Turns out Greg has been scrolling past this metadata for most of the last year. The difference is that Greg works with FCP XML exports, while Jerry and I were looking through the Final Cut Pro interface.

OMG! What a treasure-trove of metadata there is. And why didn’t we know of this? Surely someone from all the conversations we’ve had with people developing Sync-N-Link must know about this? (You’ll all come out of the woodwork into the comments and let me know you’ve known about it for years!)

So this morning Greg’s built me a tool for exploring this hidden (I prefer “secret” because it makes it seem more mysterious) metadata, turning it into an excel spreadsheet. I already had XDCAM EX media and P2 media along with RED clips and I was able to download some AVCCAM media shot with Panasonic’s HMC-150 camera.

There’s an enormous amount of Source metadata there. A lot of fields that seems to be unused even in the camera. Clearly, the current version of Final Cut Pro doesn’t have the flexibility to display items like ‘whiteBalanceTint’ or ‘digitalGainBlue’ settings in the original file. I guess this type of metadata is going to be challenging for Apple and Avid to deal with, as they don’t (currently) have displays in their application for the enormous amount of metadata that are generated with tapeless cameras. I’m just very thankful that it’s being retained, and that it’s available via XML (and associated with a Final Cut Pro clip ID).

There’s definitely metadata already  being produced that we can use to improve First Cuts – at least for non-tape media sources. But it’s also interesting to explore fields that are available but not being used.

Show all columns and you'll be surprised at what's available, or going to become available.

BTW, you can explore yourself using Log and Transfer. Open any type of media that Log and Transfer supports and then, right click on the column header (like you would in Final Cut Pro) and select “Show all Columns”. The columns displayed will change according to the type of media selected.

So far, Sony’s XDCAM EX has the least amount of metadata and the least interesting metadata – barely more than the basic video requirements and information on the device: model and serial number.  RED footage has a lot of metadata, although most is focused on the technical aspects of the shot as you would expect for a digital cinema camera.

But take a peak at the source metadata from P2 Media! All the goodness like the date of the shoot (which FCP otherwise does not export) and time (as does RED) but also fields for ‘Reporter Name’ (awesome for a First Cuts – News product) and Latitude and Longitude. While they’ve been blank in every instance because I don’t think Panasonic are shipping any cameras with GPS built in yet, it does suggest that future Panasonic cameras are likely to contain GPS and store that data in with the media file. Anyone who’s a regular reader will know that means Derived Metadata! There are also fields for ‘Location Source’, ‘Location Name’, ‘Program Name’, ‘Reporter’, ‘Purpose’and ‘Object’ (??).

AVCCAM carries all the fields of P2, more or less, with the addition of a “memo” and “memo creator” fields.

It’s been fun exploring this ’secret’ metadata. Now to find a way to make some use of it, or make it practical. Would anyone be interested in a tool that would not only read and explore this metadata, but allow some of it to be mapped to existing Final Cut Pro fields?

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 approachwith 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!

I originally wrote this to a friend over the weekend and I thought that, with a bit of an edit, it might be interesting to some others.

Last week we released two new pieces of software through my long-time company, Intelligent Assistance, Inc: First Cuts and Finisher. Collectively we call the category “Assisted Editing” because they, well, assist the editor and going with Assistant Editor was getting confusing.

What I think makes this so exciting is that it’s the first real innovation in editing since Non-Linear Editing was popularized with the release of Avid’s Media Composer version 1, 19 years ago. 19 years is a long time in the computer business. Non-Linear Editing has certainly developed since that first release of Media Composer. Then 160 x 120 16 gray images were the “state of the art” while now we effortlessly manipulate High Definition (and beyond) images in our systems. But, despite this development, the way NLE systems work today is much the same as they did 20 years ago.

What Media Composer did, was to make the “cost” (time, effort, expense) of an edit much more affordable. With linear editing bays, making small changes to, or alternate versions, of a program was difficult (read expensive). Non-linear dropped the cost of a change, revision or alternate edit dramatically. Assisted Editing achieves similar dramatic cost reductions by allowing the computer (and specifically our software) to do some of the work of the editor.

Back at NAB in April we announced “The Assistant Editor” for long form documentary editing. After three months of beta testing we have now released that application as “First Cuts”. First Cuts (for Final Cut Pro right now but we’re exploring other platforms) take the log notes made by a documentary editor (or their assistant) and turns them into very, very fast first cuts. This allows editors and producers to explore the stories that are available in the material, and to juxtapose different versions while they seek inspiration and direction.

First Cuts take the log notes that long-form documentary editors have traditionally made (and their workflow) and makes them much more useful. The logged clips are exported from FCP as XML and opened in First Cuts, where the editor chooses opening title and lower third template (Motion templates preferred), the duration and story keywords that will be used for this edit. Within seconds it creates an edit with beginning, middle and end to the story arc, with opening title placeholder and fully finished Lower Third titles used appropriately to identify speakers on camera. The edit will also have b-roll used appropriately and the audio on the b-roll is lowered in volume and faded in and out. It’s an edit a producer or finance person can watch without being distracted by jump cuts or lack of visual interest from the absent b-roll. You can see the process in a quick five minute tour at the First Cuts home page.

First Cuts is primarily focused on long form documentary editors because they have the discipline to enter log notes (if they don’t they will have a very hard time of it) and because they need to explore a lot of material. The payback is significant. Fortunately there are a lot of documentary editors working with Final Cut Pro.

We discovered that one way of working with First Cuts would be to find a cut that was close to what was desired, and then the skilled editor would add the polish, trim and emotion that a first cut lacks. In doing that we discovered that blowing away the b-roll and titles was the cleanest workflow. Since that removes a lot of the time saving, we decided to make a product that restores that finishing effort. Hence, Finisher.

Finisher takes a project with an edited a-roll sequence (aka “radio edit”) and adds Lower Third titles and b-roll as above. This is the perfect bookend product to First Cuts.

But we worked out that we could do a lot more with Finisher for those who don’t want/need to enter a lot of log notes. Finisher will work with any of the log notes that are provided for First Cuts, but does not require them. In fact Finisher can randomly choose b-roll to place in a Sequence. Location of b-roll can be forced with Sequence Markers, so obvious jump cuts are covered first. While it can run with random selection it will use b-roll search terms in the comment field of those Sequence Markers and search for matching b-roll if available.

You can see some examples of Finisher’s work, including a guided tour that shows a couple of different ways it can work, at the Finisher home page. Particularly interesting is the final example – ‘Ode to the Beach’ – because that is a simple audio recording, some b-roll pulled out of my stock collection from Final Cut Server, and Finisher adds b-roll to the cut (with Sequence Markers) randomly. The result – for almost zero effort – is quite acceptable and may even be useful in some situations.

Not too shabby for a version 1 product.