FCP Project Tips

When Avid and Final Cut editors talk smack on the internet forums, the arguments invariably get done to the strengths and weaknesses of each application when it comes to collaborative editing. There are pros and cons to each approach, but lets take a look at how Final Cut Pro editors can organize projects in such a way that sharing can be painless.

When you compare Avid and FCP project types, you will quickly realize that Avid Media Composer projects (at the finder level) are actually folders containing multiple bins. That’s where all the metadata lies. In the case of Final Cut Pro, the project file is a single monolithic file containing all the metadata. So in the simplest terms: FCP PROJECTS = Avid BINS.

The second important difference is how and where media is stored. Media Composer neatly stores all media in one folder on each media drive. All media that is ingested or imported (and transcoded) is placed into the target Avid media folder. The location of this folder on the hard drive cannot be altered by the user.

Final Cut Pro’s project window is primarily a media browser, so files can be dragged into the project from anywhere on any of the connected drives. You can also delete clips from the browser and that won’t affect clips that have been edited to the timeline. Avid controls the media location structure, whereas FCP leaves it up to the user. Avid’s method of media relinking is relatively bullet-proof, while FCP’s is more versatile, but also potentially problematic.

Here are some considerations to make your FCP project experience more solid.

File location – The most important consideration is file location. FCP has certain defaults, but people violate these all the time. Since you can drag content from anywhere, it’s very easy to grab an SFX out of the Soundtrack Pro library or an image from your personal Pictures folder. No problem when you are the only editor, but a potential disaster when you send the project to someone else to finish. Set up a structure of file organization and stick to it.

I personally feel that any extraneously-imported files should first be copied to a location consistent with that project, even if this means you are duplicating your media. If all of your media for a project is supposed to be on a single external drive, then first copy such files (images, VO, music, SFX, etc.) to a folder on that drive BEFORE you import these into FCP. When you hand off the media drive to another editor no files will be missing.

FC Studio files – Remember that Final Cut Pro is only part of Final Cut Studio. When you use other applications in the suite, like Motion, they each create their own project files. With the exception of Motion’s master templates, LiveType and Motion project files are not stored as part of the FCP project, even though they appear in the browser. The file in the FCP browser is only a link to the real project file stored somewhere else. Part of your file strategy needs to determine where these files are to be stored. For instance, are you going to store all Motion projects in a single Motion Documents folder or are these files going to be stored with the media for that project? This becomes a crucial decision if you ever have to move the drives and relink media.

Folder structure – When two editors are working on the same project and sharing media on separate drives – or a drive that is passed back and forth – make sure you each maintain the exact same folder hierarchy. This is critical in order to properly relink projects to their media. If you don’t do this, each time you have to relink, it will become an adventure searching through the folders on the drive. If the media path is identical, except for the host computer’s name, FCP has almost no problem in linking media to an FCP project on a different computer. The easiest way for two editors to collaborate (different locations, different drives) is for the media drives to be exact duplicates or clones of each other. Then relinking should be instant whenever project files are copied and shared between the editors.

Multiple projects – One of FCP’s big plusses is the ability to work with multiple projects and multiple sequences open at the same time. Large FCP project files can be unwieldy, so breaking your production into multiple smaller projects helps to control this. Each FCP PROJECT file works like an Avid BIN file (more or less). Following this philosophy, you might have individual projects for each day of dailies and for your edited sequences. But remember that the FCP browser/project window holds your metadata, like comments, timecodes, etc. and this can cause some concern when working with multiple projects. For instance, the match frame command locates master clips within a project or connects to actual media files, but not to other projects. Working across several projects within the same production might not be ideal for you; nevertheless, this way of working can be very streamlined.

Sharing sequences – Another use of multiple projects is when you share edits with another editor. There is no need to copy and send the complete project file each time someone makes a change. Instead, editor “A” makes changes to a copy of the sequence and places that into a new and separate project, containing only that one sequence. Send the file to editor “B”, who opens that project along with the master project. Copy the revised sequence into the master project and continue.

This way of working mimics the concept behind Avid Unity. Since Avid bins are separate files, Unity controls the user’s write access to any open bin. A hallmark of Unity shared storage is that two or more Avid editors can simultaneously work in the same open project file on different workstations. However, each can only make revisions (write permission) in a bin that they have opened first. The other editors only have read permission to such a bin. In order for two Avid Unity editors to make concurrent revisions to different segments of the SAME sequence, a copy must be made and moved into a separate bin, which is closed by the first editor and then re-opened by the other, in order to change the write permission. Once both have made their changes, one of the two editors must combine the two timelines back into a single timeline, which reflects both sets of changes. This is not unlike two FCP editors working with duplicate copies of the same FCP project file.

File and Volume Locking – Shared storage systems in their simplest form control read and write permissions through file-level or volume-level locking. File-level locking means that two editors on different computers can write to the same drive partition without the danger of overwriting each other’s files. Volume-level locking requires that drives are partitioned and each editor is assigned read-write or read-only permission to any given partition. The determination of file versus volume is controlled by the internal file system of the shared storage solution and the media management software used as the “traffic cop”.

Apple’s Xsan software controls media management and is a file-level based system. All editors see a single media volume mounted on their desktop. They have access to all media and Xsan controls the writing of files, such as renders. A volume-level system, like the original Facilis TerraBlock units, use multiple partitions where each editor is typically assigned only one volume with write permission. There are also some systems that use Ethernet connections and no “traffic cop” software. Instead, they rely on the OS and Apple’s internal networking structure to handle the traffic. One computer in the system is set up as the “server” and the media is connected locally to it. The other workstations access the media file over the LAN.

Simple Ethernet-based solutions work relatively well in small shops (up to 4 or 5 systems), but should be used largely as read-only systems. In other words, aside from writing while ingesting media, other simultaneous writing tasks should be kept local to avoid potential collisions. This means that editors should store project files, assign the Autosave target and render all media to a local drive. The downside to this suggestion, however, is that two editors working on copies of the same project, will have to individually render their own sequences, since the render files won’t be on the shared storage.

Using the OS – Apple has integrated many aspects of Final Cut Pro into the fabric of OS X. FxPlug, QuickTime, Apple Events and XML-based roundtrips are all part of this. When you drag a movie file from a drive location directly into the FCP browser, it automatically shows some of the metadata shared between QT and FCP, such as timecode and reel number. When you drag the project icon of a LiveType or Motion project directly from that app’s header bar into an FCP project, you have, in fact, imported that LiveType or Motion project.

If you want to get more out of your FCP experience, then use other parts of the OS. For example. Quick Look and Cover Flow can be used to browse media files. XML has opened a small industry of third party apps to perform tasks with FCP files that can’t be done by FCP itself. Spotlight can be used to find media files. You don’t have to ingest with FCP, but can use other capture utilities (like AJA or Telestream) instead, if that suits your purpose.

I’ve probably raised more questions than given answers, but hopefully these tips will form a starting point for better FCP organization. Now go edit!

©2010 Oliver Peters