FCP 8: What could have been
I was going to do a “here’s what it’s like to fine-edit in FCP X” thing, but I’m not going to bother. Continuing on from what I started yesterday I spent about fifteen minutes just kinda listlessly dicking around before realizing why I had no motivation: There’s no point. I already know I can’t get anything out of FCP X other than a QuickTime — and frankly I’m just assuming about the QuickTime thing — so why bother? No EDL out, no OMF or AAF out, no XML out or anything like it … there’s just no point in working in FCP X unless your greatest goal in life is to put something on YouTube.
So I gave up. I just quit the app. At this moment right now, I’ve got no particular intention ever to launch it again.
Instead, I want to spend a little time thinking about what could’ve been. Because it’s easy to say “Oh, this sucks” or “This is wrong” or “Fuck this, I quit.” Anybody can complain. What’s harder is to be constructive. So I’m going to try to do what’s hard.
Now, before I start I want to make something really, really clear: I am an idiot. Seriously, I don’t know anything. So every idea I put down here might be the stupidest thing anyone’s ever thought of. In fact, I fully expect that to be the case. But I’m going to do it anyway because, really, what the hell. It’s Sunday morning and I’ve got nothing better to do.
So let’s start by thinking back on Final Cut Pro 7.
Say what you want about it, but the fact is FCP 7 worked pretty darned well. Once you accepted the burden of media management and format sanitation — I’ll talk about those in more detail later — it was fast, faster than dreams. You could really be creative in FCP 7. It got out of your way and just let you be an editor. It was great, truly great, for offline creative editorial.
Of course, it had its flaws. Media management was the big one: It didn’t have any. Literally. FCP 7 had no media management whatsoever. An FCP editor had to spend a lot of time in the Finder moving computer files around, which is just about as far away from creative editorial as you can get. FCP would happily let you drag in a QuickTime movie from somebody else’s computer, mounted over the network. “Oh, you want me to play that uncompressed HD file over a VPN connection to a computer in Singapore? No prob, Bob!”
FCP, in essence, happily let you be stupid about your media. Which was a burden, to be sure. But at the same time, it was also liberating. You could set up your projects however you wanted. If you worked in an Xsan environment, you could easily — well, maybe not easily, but without too much trouble anyway — create a library of B-roll that all the editors could use in their shows without ever having to make a copy of a single frame. It was trivially easy to screw yourself, but it was also easy to do exactly what you wanted to do.
So clearly there was room for improvement in FCP’s media management. But it needed to be done carefully to keep from throwing the baby out with the metaphor.
Speaking of media, let’s spare a thought for our old friend, the Open Format Timeline. That’s what Apple called it when FCP 6 first shipped. Everybody else called it resolution independence, but Apple thought it was an important enough new feature to deserve its own name … and they weren’t wrong.
Prior to FCP 6, any shot on your timeline that wasn’t in exactly the same format as the timeline itself would give you a red render bar, and a beeping “Unrendered” alert whenever you tried to play it. But with the Open Format Timeline you could throw whatever you wanted into your timeline, and FCP would try really really hard to play it back for you in real time. Sometimes it still couldn’t, of course, and other times it used tricks like giving you a half-resolution preview instead of full-resolution playback. But that was okay! It was a huge improvement over the “render early and often” thing we had to do in previous versions, and we still had the option of practicing media sanitation if we wanted full-quality real-time playback everywhere; all we had to do was convert everything to our timeline format before editing, which sounds like a big pain but was actually not that bad in most cases.
But again, there was room for improvement. Computers had gotten beefier faster than FCP had gotten more clever. So we had these $10,000+ workstations with 24 CPUs and graphics boards that made InfiniteReality look like a kid’s toy, and FCP still struggled to upconvert SD to HD in real time. So yeah, we needed some modernization there.
And while we’re at it, FCP was never what you’d call nimble when it came to handling new media formats. For years that wasn’t a big deal; we all worked in DV, and then when DVCPRO HD came out we all switched to that. It’s only later that the floodgates opened and we got things like REDCODE and ARRIRAW and XDCAM and AVCHD and camera-raw H.264 variants and so on. But the floodgates are open, and it seems like every new camera comes with its own special format, and FCP needed to be a lot quicker to support them and a hell of a lot more thorough when it did.
Then there are the (relatively) minor things. FCP’s trim mode was never that great. The way it handled reconnecting offline media was unreliable at best. There wasn’t any built-in proxy support. The built-in color corrector and keyer were completely useless, and I don’t even know if it had any roto features; it never occurred to me to look for them, because I already knew the color corrector and the keyer were a disaster. And of course, under the hood I’m sure the program was not significantly different from what that dark space behind my television looks like: an impenetrable mess of wires going god-knows-where, more than a few of them not even connected to anything any more, and heaven help you if you need to make any changes or repairs back there.
So yeah, clearly we needed an FCP 8. Some long-standing problems needed to be fixed, some features needed to be added, and yes, it’s surely the case that the whole thing needed major surgery to make it possible for problems to be fixed and features added.
But as we all know now, Apple fucked that up completely.
So what should it have been like? What’s the road-not-taken?
I’m going to divide this into two categories: creative editorial and finishing. I imagine everybody who reads this will know what I mean by that, but just in case, creative editorial is storytelling. It’s usually done with low-resolution, shitty-looking, un-graded footage — though that’s changing now that more cameras are spitting out efficient and editable native formats — and the focus is on assembly and refinement. Finishing is where things get technical: color correction and some creative color work, compositing, titles, maybe some light audio mixing, stuff like that. If editing were carpentry, creative editorial would be done with lathes and hammers, and finishing would be done with sandpaper and paintbrushes.
Creative editorial
The big ones here are obviously media management and real-time performance.
Managed projects
The imaginary FCP 8 should have had the option, on by default, of fully managing your media. Think about how Aperture does it: When you create a library (that’s Aperture’s term for it) you get a package on your hard drive. It just says “Aperture Library” on it, and it acts like a file. Inside it are all your photos, plus the databases for keeping track of them, the thumbnails, any changes you’ve made, all that stuff.
That’s what an FCP 8 managed project should’ve looked like. I’m calling it a “managed project” here just to give it a name. It should’ve been a package that looks like a single file, but that contains all your timelines, all your media, all your everything. Yes, these things would have been terabytes in size for big shows, but that’s okay, because remember, it’s fundamentally just a folder. We all already have multi-terabyte project folders on our RAIDs, and this is no different.
The way FCP X imports media is actually pretty fantastic. When you tell it “I’m going to use this piece of footage,” that piece of footage shows up in your bin instantly. You can start working with it instantly. But in the background, your computer is working hard to copy the media to your drive, convert it to your working format if necessary, index whatever metadata’s in it, all that stuff. When it’s ready, the program just invisibly reconnects the thing in your bin to the processed and prepped media file on your drive, and that’s just great.
It needs more granularity of control, though. FCP X is opaque about the technical details; FCP 8 should’ve been very specific. It’s a project-wide set of settings: Copy media to the project, yes or no? Transcode to an editing format, yes or no? Which editing format: pick from this list. Generate proxies, yes or no? What size and format: pick from this list. And so on.
Of course, you should also have the option of not managing the media. Edit-in-place is a feature you’d miss if it were taken away entirely. But the default should be to manage everything.
Multiuser editing
There’s a side-benefit to this managed-project approach that might not seem obvious at first: multiuser.
Imagine this scenario. You’re working on a feature-length project, something with a total running time of a couple hours let’s say. The shooting ratio is a very modest 10:1, so you’ve got twenty hours of rushes. But you’re on a deadline, so the plan is to break the show up into acts and have a different editor work on each act.
With these imaginary managed projects in this imaginary FCP 8, you could have some kind of shared-storage environment — Xsan maybe, or if everybody’s using proxies even just file sharing over Ethernet, really. The project lives on the shared storage volume, but each editor just opens it up as if he were the only one working on it. The program keeps track, using a data structure of some kind stored in the project itself, of who’s got it open; there’s probably even a little pane, hidden by default, that shows you who’s working on which timelines.
Individual timelines are exclusive-access. Only one person has read-write access to a timeline at a time. Bins are read-write for everyone by default, but can be exclusively locked by, say, the assistant who’s loading today’s rushes into the project and doesn’t want anybody messing with the shots until he’s got them organized. Render files and other temporary data go into a cache folder which can be local to cut down on network traffic.
I think it’d work pretty well. But then again, I’m an idiot.
Real-time performance
As for real-time performance … well, yeah. FCP 8 would need some. Quite a lot of it, really. But we should balance real-time performance against the realities of day-to-day work by adding a hard-commit button. I’ll talk about that more in the finishing section below.
The basics are obvious: Our imaginary FCP 8 should play whatever we drop on the timeline in real time, at full resolution and full quality, without dropping any frames. That’s the goal, anyway. We all know it’s not possible. If I’m on my laptop with a FireWire 800 drive full of 4K R3D media, I do not expect real-time performance. That’s where the proxy workflow comes in.
Proxies
I know FCP X has some kind of proxy workflow, but to be honest I don’t know anything about it other than that it exists. I just haven’t looked into it. But it’s not hard to see what the imaginary FCP 8 proxy workflow should be like. Just look at Nuke.
Whenever you load a clip, you should have the option of generating a proxy for that clip. But it shouldn’t just be a radio button that says “proxies yes/no.” It should be more flexible than that. Do you want half-resolution proxies? If you’re working in HD, half-res might be just fine, but if you’re working with 4K media that won’t nearly cut it. So you should have options: half-resolution, quarter-resolution, maybe even 1/8th, just tick the boxes. In the editing UI, there should be a visual indicator of your proxy resolution. Maybe it’s a pop-up you can touch to choose 1:1, 1:2, 1:4, 1:8.
What’s more, there should be an easy way to generate proxies after the fact. Oh, I thought I’d work at full res on this job but it’s bogging down too much, so I’ll select a bunch of shots in the bin and hit the “make proxies” button or whatever. Same options as before: half, quarter, eighth. It processes them in the background, or else I can go to lunch and they’ll be ready when I get back. Whatever.
Switching back and forth between proxies and full-res media should be a very fast and easy thing to toggle. There should be a shortcut for it, obviously. Because if it’s fast, you’ll be more inclined to work with proxies all the time, then toggle full res to check your work, then back to proxies. Net result: Faster performance overall, which means more time spent being creative and less time waiting for the computer to catch up.
Background rendering
FCP X doesn’t really do background rendering. It does auto-rendering. It waits until you aren’t doing anything, then it automatically starts cranking away. Go to the bathroom for two minutes, and FCP X has been rendering for you while you were away. That’s fine and all.
But imaginary FCP 8 should have true background rendering, in the form of a separate render node app. Install it on another computer with access to yours over the network and point it at the project-or-projects you want it to work on. As you do things that require rendering, imaginary FCP 8 fires off render requests to the node over the network; the node picks them up, renders out frames and slips them into the cache where your computer can get at them.
And you should be able to have an unlimited number of render nodes.
And the render node client should run on Linux. Yes, I said it. No user interface; it should be a command-line-only tool for hard-core gearheads who work in pro environments. Your editors are complaining that their edit systems aren’t quick enough to render? No problem. Just order a few blade servers, stick ‘em in the rack and put the node client on. Job’s done.
There’s surely a lot more to say about refining FCP to be a better offline NLE, but a lot of that comes down to personal preference. Everybody wants a better trim mode. Me? I’d want a feature that marks where I stop playback, so I can watch a shot through several times and get a feel for where we should cut away. Little things like that. If you’re an offline editor, you probably have your own list already, so I’ll just move on to finishing.
Finishing
Final Cut Pro 7 was a really good offline NLE; not perfect, but really good. It was a shit finishing system. Lots of room for improvement there. But frankly? It doesn’t all need to go into the imaginary FCP 8. All of this stuff could have been held off until FCP 9.
Conforming
The first thing you always have to do when you’re finishing somebody else’s offline is take their EDL — whether it’s an actual EDL or something more sophisticated like an XML or an AAF — and conform the online media to it.
In a traditional film-based post workflow, it goes like this: You shoot everything, then the transfer house does a quick-and-dirty, middle-of-the-night transfer of all that film to something like Betacam, keeping track of which film reels correspond to which timecode spans on which tapes. You digitize that into your NLE and do the cut, then you send an EDL of your cut back to the transfer house. They convert the timecode in your EDL into edge code on the film, and go back and re-scan just the bits you used at high resolution, grading them for color along the way. Then those color-graded scans go to the finishing system, usually as DPX or TIFF sequences, and the finishing system assembles them onto a timeline using the same EDL you sent to transfer.
We still do a shitload of this today. Film isn’t any more dead than videotape is — and videotape isn’t dead at all. But we also have other workflows today, generically called “raw workflows,” that conform — heh — to that same basic outline: Cut low-res copies of the media offline, then conform just the important bits of the full-res media to your offline cut.
Final Cut Pro 7 could never do this worth a good goddamn. Imaginary FCP 8 — or FCP 9, whatever — should be able to. It should read DPX and TIFF sequences natively; it should read R3D files natively, and ARRIRAW as well if that’s possible (I don’t know the technical ins-and-outs of Arri’s raw format.) You should be able to take an EDL or an XML, or indeed an FCP 8 timeline, and auto-conform high-res media to it. It should read metadata — timecode, reel numbers and so on — out of DPX headers or R3D files automatically, and be able to identify which sequences or R3D go with which clips on the timeline or in the EDL. It should be, in other words, exactly the same as every other damn finishing system on the planet.
Scene detection
Of course, sometimes for whatever reason you don’t have an EDL. Sometimes you don’t even have high-resolution media. Sometimes you just get a finished QuickTime. There should be a way to point at a clip on your timeline and run scene detection on it. It should identify cuts in the clip and add through-edits there. In an ideal world, it’d do a best-guess to find dissolves and fades as well, but let’s not be too greedy.
A/B wipes and overlays
How many times have you had a shot on V1 that you needed to match with a shot on V2, and you had to hop up and down on the clip-enable hotkey in order to toggle back and forth between them real fast? Screw that. Build A/B functionality into the viewer. Let me choose an A track and a B track (V1 and V2 by default, obviously) and either wipe between them by dragging a little handle above the frame, or dial down the opacity on B so I can see them superimposed. We have to do this all the damn time, so it’s a thing the app should just do for us.
Pulldown addition and removal
Yes, folks, we still have to work with 3:2 pulldown. It should be possible to add and remove it in real time, with a click. What’s more, if you edit some 23.976p material into a 29.97i timeline, the app should add 3:2 pulldown automatically, using the first frame of your edit as the AA frame.
This is not hard; 3:2 pulldown exists specifically because it’s easy to do. There’s not even any math involved; you’re just rearranging scan lines. There’s no excuse for the app not to do it in real time, automatically when needed or on demand.
Color corrector
Imaginary FCP 8 should have one. No, it doesn’t need to be a full-on Resolve environment, and it doesn’t need to be as good as Smoke’s color warper. But we need basic lift-gain-gamma-type controls at least. If it’s got easy and quick support for power windows, lovely.
Tracker
At least a 2-D four-point tracker, please. 3D and planar tracking can be left to third parties to offer as plug-ins, but you should at least be able to do a quick and easy track of a billboard or a bus sign.
Stabilizer
Here’s a dirty little secret: a stabilizer is just a two-point tracker in reverse. So if you’ve done the tracker, you’ve done the stabilizer.
Keyer
No, fucking seriously. I’m not kidding about this. The keyer doesn’t have to be perfect. It doesn’t have to be as good as Ultimatte or Nuke’s IBK or even the modular keyer in Smoke. But at least it needs to be usable. If you give it absolutely nuts-perfect greenscreen footage, you should be able to pull an acceptable key with a single click. And if you give it shitty greenscreen footage, you should be able to pull an acceptable key with fiddling. Yes, it’d be find if “real” keyers were available as third-party plug-ins, but it should at least be possible to pull a key with the built-in keyer.
Roto
It should be possibly to do roto in imaginary FCP 8. It doesn’t have to be the world’s best roto tool. There will always be specialized tools that are better. But there should at least be splines, and a good and quick way to link splines to tracks out of the four-point tracker.
The magic hard-commit button
We’ve all been there: This shot needs three color corrections (a balance correction, a grade, and a relight), it’s got an element over top that was shot on greenscreen and needs to be keyed, and by the way there’s a title. One shot on your timeline suddenly becomes a stack seven tracks deep.
You should be able to select the whole stack and hit a button that says “commit.”
What FCP 8 does is render out the shot, just as it would if you’d merely rendered, then writes that render file out to a QuickTime in the managed project … then collapses your stack into a single clip on your timeline. All the information about what went into that shot is still there; you can open it back up with a keyboard shortcut or something if you want, make changes and recommit. But as far as your workflow goes, you can just forget that shot has any effects on it at all, and just treat it like it’s a single clip … because it is.
Other stuff
Some other random thoughts that don’t really fit into the narrative:
Stereo
I hate it, personally. But it’s a thing. Imaginary FCP 8 needs full stereoscopic support everywhere, as a first-class feature, not a bolt-on.
32-bit float everywhere
Should I even need to say this? Every pixel of every frame should be processed in 32-bit floating-point format. Nuke can do it on my goddamn laptop, so imaginary FCP 8 should too.
Archiving
Imaginary FCP 8 should talk directly to attached mass-storage devices like LTO drives. I should be able to archive an entire project to LTO with just a couple button-presses. Of course, I wouldn’t want to have to tie up my edit system with archiving and restoring projects, which brings us to…
“Backdraft”
Once upon a time, Discreet Logic shipped a product called Backdraft. If you’re familiar with Flame and Fire, you know they share the same library interface. Backdraft was just the library. It was for doing deck I/O, moving clips around, basically doing time-consuming assistant-type stuff on a computer other than your half-million dollar editing or effects system with the $350,000-a-year artist in front of it.
Imaginary FCP 8 should have an app like that, bundled with the software but unlicensed so you can install it on an unlimited number of computers without a key or dongle. It’s basically FCP 8, except without a timeline. You can create projects with it, make bins, load media either from disk, cards or tape. You can archive and restore clips, timelines or jobs to and from disk or LTO. It can connect to projects on shared storage or over the network in the same way multiple seats of FCP 8 can, so an assistant can be loading today’s rushes into a bin while the editors work with yesterday’s at the same time.
This shouldn’t be a separate app, per se. It should just be a piece of FCP 8 that gets broken out and packaged up as a separate program. Same UI, exactly the same buttons and switches, everything the same except no timeline.
In conclusion
Final Cut Pro 7 was a damn good offline editor. It was a shit finishing system, and a completely useless grading or effects tool.
But it wouldn’t have taken much, in terms of visible changes or new user-facing features, to turn it into a really great offline editor, an acceptable finishing system and a passable grading and effects tool.
Yes, the whole app would need major surgery, because it’s old and ugly on the inside. There’s no way around that. But in terms of actual changes to how it works, the app really didn’t need that much. The timeline worked, the whole project/bin paradigm worked. It just needed a few big user-facing changes to things like project and media management, and a bunch of tweaks.
Would it have been easy? Hell no. There are whole companies that exist just do do stuff like this, and they struggle to get it right. But remember, Apple’s got more money than God and his son the Lord Jesus Christ. If they wanted to, they could have set up a whole department, hired the right people and made this happen. Easy? No. Doable? Totally.
Worth it? Well, only Apple can say for sure. But based on what we got out of them instead of FCP 8, I think it’s pretty safe to say no, they didn’t think it was worth it.
Fine for them. Sucks for us.
