Welcome, Guest
Username: Password: Remember me

TOPIC: Best collaborative way of editing with fcpx?

Best collaborative way of editing with fcpx? 09 Sep 2017 17:28 #90418

  • Betancourt
  • Betancourt's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 109
  • Thank you received: 5
  • Karma: 5
Hi friends!, I'll have to edit a 15' length documentary on fcpx. The director is in Europe and I'll be editing in Argentina. The director also edits in fcpx so sometimes he could work on my timeline if required. The client and the team involved are from different countries. Which would be the better workflow to work this way? Frame.io? sharing projects via internet or dropbox?
Any help appreciated,

Pablo
Pablo Betancourt
Last Edit: 09 Sep 2017 17:29 by Betancourt.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 09:46 #90426

  • ronfya
  • ronfya's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 51
  • Thank you received: 4
  • Karma: 0
Hey Pablo.

I am sure you already guessed that it is best if all team members have the original media. Though not necessary since you could share only proxies (open the FCPX library package and find them there) with the other editors only.

Before editing, commit to a relevant keyword system that will help you log all your footage and stick to it until the end.

Then sharing projects is only a matter of sharing the XML of the timeline and sending to other editors.
For review frame.io was really a breeze for my last 26' doc. Best of all you can download the comments and have them in FCPX. There's a ripple training video on youtube showing you how.

I would say watch out for round-trips with your color grading app of choice and for sound editing/mixing (for which you need to use roles from start to end in FCPX to go smoothly). Test the whole round-trip with a small edit of say 1 minute long because if this operation is to cause you trouble, you better figure out how to solve them before you are reaching the deadline of your project !

On to the good work now !
Cheers
Last Edit: 10 Sep 2017 09:47 by ronfya.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 11:05 #90430

  • joema
  • joema's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 729
  • Thank you received: 157
  • Karma: 10
Betancourt wrote:
....director is in Europe and I'll be editing in Argentina. The director also edits in fcpx so sometimes he could work on my timeline if required. The client and the team involved are from different countries. Which would be the better workflow to work this way?... Frame.io?.

Besides Ron's advice, here are some items:

4k material will often require transcoding to proxy for good performance. There is a "proxy only" workflow whereby all downstream editors have only proxy material and you maintain a "lean library" for sending back and forth. It is a little complex but documented in Ripple Training's 10.3 media management class: www.rippletraining.com/products/final-cu...-final-cut-pro-10-3/

There are unfortunately some limitations in how FCPX handles proxy-only media management. Relink is not reliable which means the disk volume name and folder structure where the original proxies were generated must be used for all downstream editors. This requires renaming the disk volume name of any distributed portable drives.

Since there's no such thing as audio or graphics proxies, these must be separately added to the proxy media tree and relinked. Relink works in this case, provided the original disk volume name is used. The procedure is shown in the above Ripple Training video.

Interchanging edits and metadata via event-level XML is very useful. You can have multiple remote asst editors marking keywords and ratings in separate events, while the lead editor works on a timeline in another event. However there is no "event locking" so this requires manual coordination of who is in what event. You want such distributed metadata work consistent, so you must collaboratively determine your keywords and organizational structure. This can take considerable time but is worth the investment.

There is a 3rd party utility called MergeX which can merge metadata from multiple events: www.merge.software/

There is unfortunately a bug in FCPX XML processing which applies if your cameras (such as Sony) produce non-unique filenames. Even if kept separate in their own folders, after import they trigger a situation whereby XML interchange is unreliable and produces spurious duplicate clips. The solution is all files in the entire effort must be uniquely renamed before import. We do this with A Better Finder Rename: www.publicspace.net/ABetterFinderRename/

Using the above methods it's possible for several geographically remote editors to collaborate different elements of a single project. This style emphasizes contributory collaboration where each person is actually doing work, not comment-only collaboration where people say "I like this shot".

However it is easy to get confused about who is doing what. It would be nice if FCPX had some kind of cloud-based distributed locking system to facilitate distributed collaborative work within the same library. It need not be highly complex, at a minimum event locking and the contributor's name. Finer-grained approaches such as project locking would also be possible without incurring excessive bandwidth. Hopefully a single system which worked in both a LAN and wide-area environment could be devised.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 14:46 #90432

  • Betancourt
  • Betancourt's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 109
  • Thank you received: 5
  • Karma: 5
Ron wrote:
I am sure you already guessed that it is best if all team members have the original media.
Yes, the idea is that both the editor and me will have cloned hard drives with the original material. I'll probably work with proxies for better performance, as Joema suggests.
Then sharing projects is only a matter of sharing the XML of the timeline and sending to other editors.
This is what is not that clear to me. What is the advantage of using XML compared to sharing the fcpx project (without render files)? XML seems to have some tricky round trips as Joema stated.
Many thanks for all the suggestions!


Pablo
Pablo Betancourt
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 16:41 #90433

  • Karsten Schlüter
  • Karsten Schlüter's Avatar
  • NOW ONLINE
  • Moderator
  • Posts: 2892
  • Thank you received: 511
  • Karma: 65
what about Mike Matzdorffs "'The most awesome tip in the world' … ? ;)


www.fcp.co/final-cut-pro/articles/1806-f...lti-user-environment
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 19:52 #90435

  • Betancourt
  • Betancourt's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 109
  • Thank you received: 5
  • Karma: 5
Hey Karsten, I've seen that episode, but I thought that it was oriented for a Server collaboration. Should this implementaion work with dropbox or something similar?
Because we'll be working on different countries.
Pablo Betancourt
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 19:53 #90436

  • joema
  • joema's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 729
  • Thank you received: 157
  • Karma: 10
Karsten Schlüter wrote:
what about Mike Matzdorffs "'The most awesome tip in the world' … ? ;)

Mike is talking about sharing on a continuously connected, high-bandwidth LAN environment. Pablo is talking about collaborating in a geographically dispersed, sometimes-connected environment with slower links.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 20:50 #90438

  • joema
  • joema's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 729
  • Thank you received: 157
  • Karma: 10
Betancourt wrote:
....What is the advantage of using XML compared to sharing the fcpx project (without render files)? XML seems to have some tricky round trips...

By sharing the project I assume you mean sharing the entire library. That works but you can't work concurrently because whoever loads the library effectively overwrites any work done. But it's OK for sequential collaboration such as the editor handing off to color correction, etc.

If the library was renamed then sent to our collaborator, he'd still have to look through it and try to figure out what changed.

To avoid this the usual practice is copying the project to a smaller transfer library and sending that. If the transfer library is on the same drive, when the project is copied to it no actual media is transferred, only the project. Then you close that transfer library, zip it, and email it to your collaborator. He unzips it, opens it and the project either relinks b itself (if drive name and folder tree are the same between the two machines) or you must manually relink it. After that your collaborator has the project aka timeline with the new edits.

However in the proxy-only case, relink is not reliable in my experience. Therefore you must maintain the same drive name and folder structure. Besides this there are various other "gotchas" and details such as how to deal with custom Motion content, non-video graphics and audio files, etc. The Ripple Training 10.3 Media Management class covers those.

But the Ripple class does not cover collaboration via XML -- I don't know why. If the collaboration involves metadata such as sending updated keywords and ratings, that must be done either by sending the entire library (which is impractical except for sequential collaboration) or via XML. I think you'd normally want to segregate work by event. Maybe you could copy an event to a transfer library on the same drive, not consolidate it, send that. However any steps like this must be tested and retested. This entire area is filled with pitfalls and blind alleys.

Besides the Ripple-described procedure of sending an updated project via transfer library, you can also just send the project XML. I've done that and it works. However there is always the lurking "duplicate clip" problem after loading an XML if any of your original disk files are not globally unique. Maybe this doesn't happen if only loading a project XML but it definitely happens if loading an event XML.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 10 Sep 2017 22:04 #90439

  • Betancourt
  • Betancourt's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 109
  • Thank you received: 5
  • Karma: 5
By sharing the project I assume you mean sharing the entire library.
Yes, I'm sorry for the wrong term.
it's OK for sequential collaboration
I think this will be the approach considering that I'll be doing the majority of the editing and the director will require some changes AFTER my edit, so I think we can go back and forth as many times as neccessary. I'll try the XML approach, but considering your experience, it doesn't look too much promising. Hopefully FCPX 10.4 will give us more powerfull tools on this task.

Many thanks for the great support.

Best,

Pablo
Pablo Betancourt
Last Edit: 10 Sep 2017 22:05 by Betancourt.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 11 Sep 2017 05:11 #90443

  • Karsten Schlüter
  • Karsten Schlüter's Avatar
  • NOW ONLINE
  • Moderator
  • Posts: 2892
  • Thank you received: 511
  • Karma: 65
joema wrote:
…Mike is talking about sharing on a continuously connected, high-bandwidth LAN environment. Pablo is talking about collaborating in a geographically dispersed, sometimes-connected environment with slower links.

… I was aware of the difference …
… if you need simultaneous collaboration.
How I understood the OP, in his case, 'real time synch' isn't needed …

What is so charming about Mike's technique is: it shows how to swap smaller files to synch a full project … let me call it a 'proof-of-concept'.... and, and as far as I understand (definitely NOT my core competencies LOL), if real-time is no asset, can be done via slower services either …

… was meant as a suggestion … DIY tinkering, cheap.
(creeping back under my stone …)
Last Edit: 11 Sep 2017 05:13 by Karsten Schlüter.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 11 Sep 2017 14:07 #90452

  • joema
  • joema's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 729
  • Thank you received: 157
  • Karma: 10
joema wrote:
....There is unfortunately a bug in FCPX XML processing which applies if your cameras (such as Sony) produce non-unique filenames. Even if kept separate in their own folders, after import they trigger a situation whereby XML interchange is unreliable and produces spurious duplicate clips. The solution is all files in the entire effort must be uniquely renamed before import. We do this with A Better Finder Rename: www.publicspace.net/ABetterFinderRename/...

A workaround for the above problem is using a transfer library to send the event updates vs using an event XML. This is a little more complex, especially for a proxy-only workflow but it seems reliable. In this scenario source and destination machines have a large library composed of multiple events, and an editor has been busy marking keywords and ratings and wants to send metadata updates for that event to a colleague. For this to work the receiving editor must have not done any work in that event because it would be overwritten, but this assumes coordination of who is working in what event.

It also assumes a proxy-only workflow using external proxies (not inside the library) whereby all downstream editors only have proxy data and the upstream editor has both proxy and original media. This could be done without proxies but that is our workflow. Since there's no such thing as proxies for audio or graphics, those files would have been previously distributed to all downstream editors, typically within a subfolder inside the external proxy media folder. The procedure for this is in the Ripple Training 10.3 Media Management class.

(1) Do updates to event on source machine. To send these updates to a geographically distant destination library having several events:

(2) On source machine in FCPX create a separate transfer library. Check that the media storage location is on the same disk volume; this enables FCPX use of hard links to create the library without moving the media.

(3) Drag/drop the updated event to this library. Answer yes for copy proxies, no for optimized media. This could take several min since it must create audio waveforms in the cache. The media storage location in the library inspector will still be set to the proxy media folder. However the event proxy files are not actually copied to the new library since FCPX knows they are on the same drive volume and uses hard links to reference them.

(4) Close the transfer library which now contains the updated event.

(5) The transfer library should be pretty small, no bigger than 100MB. Zip this and send it to the recipient.

(6) Recipient will unzip and open that library, and it will automatically link up with the proxy files on their hard drive, assuming they are all using the same volume name and folder structure. If volume or folder structure differ, relink seems unreliable for the proxy-only case. It does work without external proxies and it works for audio-only and graphics.

(7) Recipient then deletes the original event from main library (after making a backup of the library) and drag/drops the updated event from the transfer library to the main library. This copies the entire event, inc'l all edits and metadata changes, to the main library.

8. Any audio or graphic files might be red thumbnails marked "missing". This is because there's no such thing as audio or graphic proxy, and these must be relinked.

Relink procedure on the receiving end (audio described):

(1) In new updated event on destination machine, select "Audio only" smart collection. All the audio clips should be red. Select them all with CTRL-A.

(2) File>Relink Files, and point to the "AudioProxy" folder within the main external proxy media folder. Select relink. This could take a few minutes depending on media folder size.

(3) When the relink of audio files completes, the updated event should be on the receiving machine with no problems.
The administrator has disabled public write access.

Best collaborative way of editing with fcpx? 12 Sep 2017 11:54 #90471

  • ronfya
  • ronfya's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 51
  • Thank you received: 4
  • Karma: 0
A lot of good things have been said here.

I would add maybe the most important tip of all (even tough it can be easily overlooked too): each collaborator must backup his own COMPLETE library every now and then, and especially before importing XMLs or other big stuff he receives. Then, in case something's messed up, there's still the possibility to go back to a safe place and re-test until you get a working workflow.

Like I said previously, on the last doc I did, I shared XMLs with the other editor and everything went smoothly (and we had indeed hard drives with the same name and folder structure ). I forgot to say that you should not work on the same stuff at the same time as your collaborators but joema explained that in great detail so you should be good to go :D

Good luck !
Last Edit: 12 Sep 2017 11:55 by ronfya.
The administrator has disabled public write access.