Apple Final Cut Pro X Debates Forum
FCP-X in a shared environment. Great article.
FCP-X in a shared environment. Great article.
by Bill Davis on Jan 6, 2014 at 6:52:19 pm

Shop in London obviously with lots of X experience has released a guide to the new 10.1 update for shared editing environs.

Extremely informative.

(was sent the link from Mike Horton and the LAFCPUG team)


Know someone who teaches video editing in elementary school, high school or college? Tell them to check out - video editing curriculum complete with licensed practice content.

Re: FCP-X in a shared environment. Great article.
by Rich Rubasch on Jan 7, 2014 at 3:55:32 pm

Just got a little excited about the possibilities.


Rich Rubasch
Tilt Media Inc.
Video Production, Post, Studio Sound Stage

Re: FCP-X in a shared environment. Great article.
by Herb Sevush on Jan 7, 2014 at 5:11:00 pm

Excellent article. Thanks for posting.

Herb Sevush
Zebra Productions
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf

Re: FCP-X in a shared environment. Great article.
by TImothy Auld on Jan 7, 2014 at 7:46:29 pm

Very interesting to see how an organization is integrating FCP X into an involved workflow. Thanks, Bill.


Re: FCP-X in a shared environment. Great article.
by Kannan Raghavan on Jan 8, 2014 at 1:18:21 am

Thanks for the article Bill. Very interesting.

Kannan Raghavan
The Big Toad Films Pte. Ltd.

Re: FCP-X in a shared environment. Great article.
by Peter Gruden on Jan 8, 2014 at 12:31:05 pm

The author Alex Snelling is an excellent FCP lecturer, which is quite evident from the text - start easy and simple, so that everybody feels confident, and then you don't even realize when it becomes quite complex.
He is also an experienced filmmaker.

I had a pleasure to attend his week long FCP 7 seminar in Prague a couple of years ago. Personally, he is a nice and laid back guy.

Re: FCP-X in a shared environment. Great article.
by Pawel Kasprzak on Jan 11, 2014 at 5:16:54 pm

The article is informative indeed, but - as it suggests - there's still a lot of testing ahead of anyone who wants to use FCP X in a complex shared workflow and a great deal of uncertainty as well, I'm afraid.

Picture a situation. You have a load of ingested HD media. Say 500 hours and you have it stored on an xSan networked drive. Most of that media comes in multi clips, say, 8 angles each, so forget about doing your job pulling the media directly from the server. You need proxies that are local. Your 500 hours is stored in 5 different events (A, B, C, D, E) and you have 4 (a, b, c, d) editors working on them editing different parts of the same episode.

Even though you have different events, there's no way to tell, who of the editors will use which of them. They all need all five. Obviously there must be a collection of those events (say, single library) that has all proxies generated and identical copies of such "base library" is sent down to editing workstations (single file libraries make this easier). The base library contains things like multi clips and compound clips, which is worth noting.

Now editor "a" makes three different projects using media from events A, B, C (he's actually barely aware of the relation between his projects and events - soon after he finishes, he hasn't got the faintest idea, which of the events he used).

Editor "b" makes another two projects, based this time on B, C, D, E events. Etc. Finally one of the editors will have to put all those projects together and do some final editing that requires full access and involves some reediting.

If A, B, C, D, E were just events storing media plus some metadata like keyword collections, then a sheer XML export of the project file(no events required) would do the job, because FCP would simply create an appropriate event that contains all of the media required. There will still be some mess about the proxies and how to link them, but at least an EDL-like information is saved and secure. The thing is projects use multiclips and compounds. Those can't be relinked when the event is missing. So obviously anyone exporting and exporting any project XML must have appropriate events loaded. And must know which of the events to load. Obviously all five should be loaded. This was sometimes tricky in FCP 10.09 (big events would sometimes take a day to open), now it's way faster in 10.1.

But editors do their own multiclips and compunds during the job. To make things worse they also modify what was done previously in their base libraries. They import new files like music and they of course do create their own events.

So having 5 events and 4 editors you instantly end up with at least 20 events that must be loaded to see all of the edited stuff. And it's just to start with of course, because people continue to work so that you not only have an original "base" event A, and not only its' mutations Aa, Ab, Ac, Ad made accordingly by editors but also versions Acb and so forth - exponentially.

Of course this all can be done, but...

I think shared workflow will become a workflow rather than a total mess only after Apple finds a way to make libraries really shared with read and write access in database terms. Not that while one guy edits things others can only read (impossible now) but that all of them have a read-write access and only the "record" being currently edited gets blocked.

Re: FCP-X in a shared environment. Great article.
by Pawel Kasprzak on Jan 18, 2014 at 1:08:53 pm

Another thing about shared environment.

Version 10.1 made it considerable easier, but for many reasons we have to use proxies here. Various scenarios described in a cited paper rely on XML exchange. This, btw, can be easily done without exporting but simply replacing appropriate "currentversion" files from the Finder level. The advantage is that proxies jump in, which doesn't happen with the project or event imported from XML.

In such cases proxies can be manually added (Finder again). Worth noting however this doesn't work if the events structure and content changes within the libraries - the proxies, even while copied, don't show up.

The paper doesn't care about proxies that much assuming that thanks to powerful hardware solutions it's easy to create and to store them. Well, our smallest libraries are still over 1TB in size.

What could help a lot would be to make proxies external. I don't see the reason why they can't be shared if originals can. But first of all it would help a lot if I could relink not only originals but proxies as well.