sharing a project internationally

Is there a good workflow for sharing a project with another editor on a remote system where drives cannot be shuttled back and forth?

I need to collaborate with an editor working in Korea. My thought is to start by sending him a clone of my media drive, and then use something like LiveDrive (http://www.livedrive.com/ForBusiness) to keep his drive and mine mirrored on a nightly basis. We could email project files back and forth, or perhaps keep a common set parked on dropbox, so that we're literally working on the same project files (obviously not at the same time). Since the project file lives in RAM, there shouldn't be a performance hit, but if there is, I believe dropbox can sync to a local folder as well, or perhaps we make the project file part of the LiveDrive routine.

With this type of setup, can FCP be fooled into thinking that it's always on the same system, thus avoiding an relinking issues?

Is there a better way to do this?

Thanks.

> Is there a good workflow for sharing a project with another editor on a remote system

Sure. It all depends on your file management. Even if your file paths are different, if both editors are organized and know exactly where their media is, and if the project is set up well to begin with (ie. no duplicate file names, file names and folders that make sense), then it's as simple as e-mailing or FTPing XMLs or FCP project files.

Relinking is no trouble at all when the operator knows exactly where to go, and when the media isn't in 12 different, unnecessary locations. I've done relinking over the phone, talking to an operator who doesn't know FCP very well, because I know the file structure so well.

If I were the one who'd created the file system, I wouldn't even bother with the "drive mirroring" stuff. Unless the other editor messes up my file-management system.

> so that we're literally working on the same project files

In my experience, I've always found it better not to work on the exact same project files.

Whenever I've shared projects with other editors, I always just send them whatever's actually been changed (Sequences and occasionally bins/clips/Browser items). I rename the Sequences so that they're traceable to a version number/date/time, and the other editor copies it into his/her own project file. It makes the transport files smaller, and also helps them pin-point exactly what's new, rather than confusing them with the whole project every time. It also allows the other editor to customize his own Browser to whatever works for him.

Working on the "same" project files on different stations, for me, risks more confusion. If Editor A and Editor B both open files called "Titanic 080411.proj" and then make different changes, and they accidentally save over that same file name, then how do you tell one from the other without painfully laborious piece-by-piece comparisons?


www.derekmok.com

>Working on the "same" project files on different stations, for me, risks more confusion.

I agree with Derek on this. It's like sharing bins in Avid. Work on different parts of the project with different file names, then compile it at the end.



www.strypesinpost.com

> Work on different parts of the project with different file names, then compile it at the end.

That's another good reason. Compiling and editing require different file-management approaches. If individual scenes are locked, or very close to locked (eg. takes have been selected, just trims), then you don't have to be bogged down by the dailies bins.

The beauty of the old FCP approach (before FCPX broke everything) is that you can copy/paste, mutate and migrate projects very easily. You can create a project file just to contain what you're sending an editor (eg. music edits/selects for a scene). The minute they receive everything, you ditch that project file. Very convenient, very fast, and risk-free if you know how to manage your main project file vs. the "transport" projects.

When I was working with three other editors on a reality show, with media in network storage, I also came up with the approach of having the assistant editor (who was excellent) make his notes on an FCP title card, stored right in the Browser with today's date, and colour-labelled. Every new day has a "transport" project containing only changed elements, and the notes are right there -- you open it from the Browser and there's all his work documented. (Basically a "readme", but without ever leaving FCP itself)

We copy the transport project to our local drive (which protects the integrity of the original) and copy the contents to our own work projects. With the assistant's work backed up, we can be free to change our own project files as we need.


www.derekmok.com