Is there a good way where two people can work on the same project if they're a thousand miles away from each other? This of course assumes that each has a copy of the Library with all of the media. Is there a good resource where I could look into doing this? Would it just be easiest to send un-managed libraries (without media files in them) back and forth when changes are made?
Even though I'm not collaborating with anybody I think there is only a software/service called Postlab that actively manages the exchange and collaboration of FCP libraries.
Now they have been sold to the company Hedge and since then there is no public news about what the development state is.
Felipe Baez (the guy who does the FCP live show) did present it at the Creative Summit so it must be working.
But I don't know where you could find more info?
Doing it yourself I think the best way would be to work out a way to exchange XML files of events and projects. If they link to the same media structure and exact same media files you could relink to your local media once you receive an XML.
Maybe somebody else has a trusted workflow that they can describe. Would be interested too
Redifer wrote: Is there a good way where two people can work on the same project if they're a thousand miles away from each other? This of course assumes that each has a copy of the Library with all of the media. Is there a good resource where I could look into doing this? Would it just be easiest to send un-managed libraries (without media files in them) back and forth when changes are made?
Yes you can do that, and the libraries are very small - provided you also keep the cache outside. Use the library inspector>Storage Locations>Modify Settings>Cache to do that.
The library bundle is a folder tree so ideally should be zipped before emailing or sending via file transfer.
For proxies to work, both local and remote editors must have the same media in the same folder tree and on drives with the same name. If proxies are not used, you can just relink.
Ideally the libraries should have different names to avoid confusion on one end. One method is create a "transfer library" and copy only the relevant project or event, then send that library. This helps to avoid a "data fork" problem whereby editor #1 and editor #2 are working simultaneously and there's no easy way to merge the data.
No clip or project should ever be copied "bare" between libraries. They should always be inside an event. This is due to some FCPX media handling issues.
You can also send items via XML but there are some limitations, esp. regarding duplicate filenames. All media filenames throughout the tree should be unique, else it may create spurious duplicate clips.
The MergeX utility can help merge work from two different editors via XML. But it's not magic and should be studied and tested carefully before using in production:
joema wrote: No clip or project should ever be copied "bare" between libraries. They should always be inside an event. This is due to some FCPX media handling issues.
I'm not quite sure I'm understanding this. So if a new file is added, like a JPEG image, then an entirely new duplicate drive would have to e sent out with the Libraries containing the event? We couldn't just e-mail the JPEG and drop it into the same Event, etc?
The main issue is moving clips or projects via drag/drop or FCPX menus between libraries on one machine. That should be done inside a "transfer library" to avoid link issues and spurious duplicates. You create the event in library 1, copy the clips/projects to that event, then copy the event to library 2.
If site #1 imports a new .jpg and site #2 independently imports the same .jpg, that is OK.
If site #1 wants to send site #2 an already-imported compound clip, sync clip, multicam clip or project, that should be done in a transfer library. So if you never make a mistake and only send basic clips or .jpg files, that can be done outside a library or transfer event. I think there may be some risk even for a simple clip if copied between libraries on one machine if not inside a transfer event.
There is a separate issue if collaborating via XML and all media files are not globally unique on disk. E.g, if you have three files named C0001.mp4, and they are in separate folders, then loading an XML from a remote user with the same media can cause spurious duplicate clips within FCPX. To avoid this always have totally unique filenames. This is easy to achieve by renaming the files or adding an incrementing serial number to each file before import.
There are several undocumented and semi-documented issues with FCPX media management. In FCPX Virtual User's Group #7, Sam Mestman described some of these. Unfortunately all those videos have been taken down by PixelCorp, which is a tremendous loss of valuable material to the FCPX user community:
Depends on the level of collaboration you are looking for.
Want to work on the same edit same time?
I don't see a lot of option out there -yet-.
I have seen a couple companies demoing doing a streaming service like Google Stadia but just for very high end workstations for 3D, editing, VFX. I guess it's just the next evolution in render farms.
Just need to review an edit? make notes?
Frame.io All day, every day.
Love it, and use it with clients on the other side of oceans daily.
Reliable, fast, and rarely any issues.
Realtime collaboration with multiple editors?
Not the answer you are likely looking for but this works great in Davinci resolve.
Why apple hasn't/cant/won't do collaborative edits like this, I don't know. Seems like a no brainer. (and maybe they have based on the multiple playheads found under the hood of FCP)
Actually Frame.io is great as sharing new media to be added to Libraries, sharing "Transport" Libraries, it's very FCPX friendly. It helps share basically any file format faster than any other service online. Don't sell it short.
And yes, Apple missed the boat from day one on collaborative editing and professional audio mixing/mastering for video.
AV-Ultra wrote: ...
Realtime collaboration with multiple editors?.... this works great in Davinci resolve.
....Why apple hasn't/cant/won't do collaborative edits like this, I don't know. Seems like a no brainer...
Resolve collaboration is based on using a PostgreSQL client/server database. FCPX is currently based on SQLite which is a single-user database code library that runs within the FCPX process. For FCPX to support multi-user concurrent collaboration would be a major architectural change.
Resolve only supports one collaboration model - co-located editors on a LAN. That is OK for an old-style large production but increasingly collaboration is cloud-based, decentralized and decoupled in both time and geography. Collaborators in different regions and time zones need the ability to work together. Resolve collaboration does not provide that.
Resolve collaboration (like the product itself) is complex. The manual is 3,016 pages. Shipping a product that complex is the anthesis of Apple's goals. Might it be possible to provide reliable cloud-based NLE collaboration with less user-facing complexity? Maybe something like Google Sheets? Possibly, but there are several issues.
Resolve (like all other NLEs except FCPX) is centered around the timeline. "Collaboration" in this context means co-located users on a LAN can edit or color grade bin-locked material. However actual post production involves a lot more than editing a timeline. A major advantage of FCPX is built-in features to organize and query material -- before ever touching a timeline. This aspect of workflow would also need a collaborative mode.
Resolve collaboration does have one really cool feature - the ability to visually compare timelines and merge differences. It is essentially a graphical timeline "diff" tool.
So there are multiple aspects of collaboration that FCPX developers would ideally need to consider:
- LAN vs cloud
- Continuous connection of collaborators vs intermittent connection
- Event Browser collaboration vs only timeline collaboration
This could imply need for a distributed On-Line and Off-Line Transaction Processing database, which has major development cost, testing cost, and support cost.
I'll add my 2 cents about what we do. As others have noted, the best way to collaborate is to use lean libraries, meaning that the cache and all media live outside the library, on external storage. We use a nice free program called Post Haste to create a folder structure for every new project. You can do this manually of course, but we like this program because it automates everything and keeps things consistent.
We also just transfer libraries like Joema suggests, but often we just send our latest libraries back and forth... we call them 'project libraries' because we use them just like FCP7 projects or Premiere project files. We version them, send them around and usually tag them with our initials. Since all media and cache are external, these files are small.
If someone sends their library via email or whatever, you can open it up. Make an event in that library called something like TRANSFER, and copy whatever you need to transfer into that event (often this is an updated timeline). Then open your own library and drag that TRANSFER event over. You should now have your collaborator's timeline in your own library, and it should link to all the media that's in your own library if they are the same. If there's new media, you won't have it obviously and it will be offline until you receive it, put it into the right place in your external folder structure, and then relink it.
This all works whether you have a remote collaborator or something like an assistant next to you handing over stringouts or whatever. If someone is doing keywording, tagging, organization, you'll be able to merge it back using something like MergeX.