As a longtime FCP editor, I’m not alone in my quest to find the replacement(s) for the end-of-life Final Cut Pro 7 that Apple sent packing last summer with the release of FCP X. I’ve spent a decent amount of time with X, and there is plenty to like, but in its current form I can’t use it.
Despite the great strides Apple engineers have made in updating this brand new application, the way X handles multi-user environments is almost a joke. Apple has published a whitepaper outlining “best practices,” some of which are hilariously convoluted. Because of the database driven nature of X’s Event Library, only one editor can connect to a particular event at a time. The workarounds include lots of duplicating and importing, resulting in redundant media and alias files on a shared volume. One or two editors may be able to handle this house of cards (indeed, the whitepaper’s examples never exceed two edit bays) but if you introduce more people into the mix things will get confusing, and fast.
This is not a dismissal of FCP X at all. I really like it, and I eagerly look forward to what I hope will be an elegant solution to the problem I describe. A “Final Cut Server X” that acts as a front end for checking projects in and out and managing an ever growing Event Library would be a godsend. On both iOS and OS X, Apple seems determined to remove the tasks of Finder level file management from the user, so it seems natural that they would extend this philosophy to their flagship editing product. We shall see.
In the meantime I have been exploring Premiere Pro CS6. In many ways it feels like a natural extension of FCP 7, and most editors used to Apple’s legacy app could open Premiere and start cutting basic projects almost immediately. As many have pointed out, Adobe even threw the FCP 7 keyboard shortcuts in as one of the layout options to ease the transition.
One key difference in the philosophy behind Premiere is how it handles formats as you edit. In FCP 7 your sequence is basically a container in a particular format (ProRes, uncompressed, etc.), and anything you throw into that container is rendered out in that same format. Premiere truly mixes native codecs (and framerates) in the timeline, playing them back as smoothly as possible in real time without rendering. It’s only when you are ready to deliver that you choose what format your finished edit will be. The upside is much less rendering and transcoding before and during the edit. The downside is you need to build in time on the back end for potentially lengthy exports. There’s no quick solution for delivering a project that’s a mix of DNxHD, RED, XDCAM, and ProRes when the final approval comes in and the client wants to walk with a file or master as soon as possible.
Premiere’s media management could also use some work. It’s way too easy to break the link between a clip in a bin and the source media on the drive. A consolidate function that transcodes your final edit into a unified format to send to a product like DaVinci Resolve would be nice, but Premiere can’t do that. To me, this is one of the shakier parts of Premiere in its current form, and I expect Adobe will be addressing this in forthcoming updates.
Earlier today, Autodesk released a new batch of tutorial videos showcasing Smoke 2013 for Mac, and I have to say that everything I’ve read and seen about this latest iteration has me extremely interested. We’ve had Smoke systems at our shop for years, but I could never get past the radically different way the software required editors and artists to work. This new release has a traditional NLE timeline workflow that is surprising in its familiarity, but with deep and comprehensive tools just beneath the surface. Everything looks clean and thought out, and the real world needs of the editor seem to be their top priority. The prerelease build was supposed to come out today, but has been delayed as they iron out a few bugs. You can bet I’ll be there when it’s released.