Sharing Large Projects? 10.1 has the answers, just know where to look!

Hi All,

10.1 is really nice-so far, much faster and more stable in Mavericks, especially. Updating was more intimidating than actually difficult thanks to articles featured here on FCP.CO like:

www.fcp.co/final-cut-pro/tutorials/1304-...raries-the-smart-way

However, project sharing, is still a bit of a consideration, rather than a feature, at this time IMHO. Thankfully, there are some really key options for media management in 10.1.

Teams of editors are not always in the same room, let alone the same state, country, etc.






The best way I can see to currently share your large projects as quick, small, files (when geographically challenged) is to keep your media external and use "transport libraries" to send to another editor. (Although you have easy recursive options here if your media is in your library already, which I will get to in a minute.)



This is if you want to do the sharing process quickly and stay in App. If your media isn't kept external, then FCPX wants to copy it along with your project as it crosses Library boundaries, which, if the other editor has the same footage, is not only unnecessary, but creates an edit file (Library DB) way too large to be practical to share via the web.



*The really GREAT news is that you can opt to choose whether your optimized media, etc. goes along with your Project. **Better yet- even IF you put your media into your library, you can always, quickly (if onto the same drive) move it out again (move, not copy, which is awesome) with external consolidation, using the updated and kinda NEW Consolidate Files feature which can help you archive clips per project, move clips per project, move clips per event, etc. A huge update in 10.1.





I suppose and probably with varying degrees of stability (I guess we will see in the coming months), show your "package contents" in the Finder and copy and paste the Event's Event file (Your actual Project file now) to DropBox, email, HD, etc. to share with another editor, who could then load that .zip file into a new or existing library. I don't think I'd go this route personally, but time will tell what works best for everyone, as of course, everyone's needs are different.





Sharing your metadata only Library Backups by setting them to a shared locale like DropBox will also be an interesting development amongst FCPX.1 users...




I shouldn't ignore Project XML export as a viable option for some, although, that type of exchange's success can vary when dealing with more complicated edits..





Interested in your thoughts!
Dusty

Or, just export an XML of your Project timeline and email it. It has been updated and is pretty all inclusive now. That's the only way I'd go. I'd not send Libraries back and forth.

One other alternative is to send the Library auto backup files. Not sure if that would work, but something to look in to.

As you can see from the above example that isn't always consistent for everyone Ben...

Again, it has been updated and works much better now. Not sure what would be inconsistent with the new updated FCPXML.

Both editors need to have identical Events of media, as is with any NLE.

Well, NO ONE is denying that, but it doesn't change the fact that XML exchange isn't as reliable in all instances as the actual project. Unless you can explain the import errors above.

I don't know what sparked this, but I'm not bashing sharing, I'm trying to help.. as for your other suggestions of exploring auto back ups and not sharing regular metadata only library DBs, (why not?) I covered the back ups and whether you elect to share metadata libraries is certainly, only, one of a few choices, thankfully.

As per your edit, our events aren't always synced depending on what/where we are in our workflow. XML works better for us for Events only or passing rough edits/projects with notations via markers, etc.

I'm sharing Project XML with someone today for testing, and we're having great success. I'd want to know more about the media in your Events, and what is different that XML is not able to read.

I've moved an Event folder from one Library to the other, and FCP won't see it. It seems if the Library didn't create it, itself, it is not an entry in the Library's database. A Library doesn't scan itself for new stuff, like FCP did before with Final Cut Event folders.

Dustin!

I actually think you're right on, man. Passing Xfer libraries is the way to go. JUST KEEP YOUR MEDIA OUT.

Easiest trick I've found is to build your library... duplicate it in the finder (as well as your external media) onto a new drive, then hand it off to the new editor. If you keep your directories straight, all they'll need to do is reconnect one file, and they'll be good to go.

Then, make a XFER library, and just put the new stuff you want to send back and forth. You can even mount this from Dropbox. Just remember to close it when you're done using it so the other editors can open as they need to.

Alternatively, if you're on a SAN... make multiple duplicates of the initial library (keeping all media external referenced on the SAN as sym links), then pass projects, compound clips, whatever, back and forth in a single xfer library... and you can keep track of everything in that library if you sort by content created.

Every editor has a cloned library that can customized as they choose from that point forward. All projects will automatically reconnect as they are passed between libraries. It's pretty foolproof, really, and if you keep your libraries small with your media outside of them... it's REALLY portable.

Also, you can have a duplicated proxy library on a portable disk if you want to take stuff home from the SAN.

Thanks Sam!

My thoughts exactly- keep the media out and if it's in, there are great in-app options now with consolidation for moving that media wherever you'd like, in very little time. And I LOVE the moniker "XFER" for transfer libraries.