Project in Use - What does this really mean?
Folks, I am archiving a very large episodic project spread between multiple drives(for other editors) and reconciling those events and files against the master drive and events from which the media came. Unfortunately to this day I have yet to solve the FCP X problem of duplicate clips and projects when dealing with moving or copying events via FCP X menu items or exporting/ importing XMLs.
Attempting to delete duplicate projects I keep getting the "Project in use" dialogue window on one project so I go to the other duplicate which I can delete. When I get this dialogue window the projects aren't loaded in the storyline window. How is FCP X differentiating between one that I can delete and one that I can't? Is there a way of seeing this ahead of time so I can isolate project and clips that are deletable; perhaps in a column status. The only difference I've noticed is that the duplicate projects are bound to separate events (episode 01 and episode 02 events) according to the inspector and in the same library, yet oddly these projects bound to another event are in the event (episode 2) from which I am trying to delete them. I don't have a "projects" smart keyword collection selected, but rather only the event instead. Something is amiss. The episode 01 projects should be in the episode 1 event.
[Tangier Clarke] " I have yet to solve the FCP X problem of duplicate clips and projects when dealing with moving or copying events via FCP X menu items or exporting/ importing XMLs."
I know two situations which can cause spurious duplicates and mis-linked files.
(1) If the original media had duplicate filenames, even if those were kept in separate folders. This creates a "name space collision" since FCPX sometimes places those files or symlinks within the same folder.
FCPX tries to solve this by appending a "uniquifier" suffix (fcp1), etc. to the file or symlink. However it doesn't work right in all cases, such as when loading an XML.
The XML dialog gives you two options: replace or keep both. Even if you say replace it may still create a duplicate clip. I filed this as a bug with Apple about two years ago.
Our solution is rename all files before ingest so they are globally unique by appending a 5-digit incrementing serial number. We use the 3rd party tool "A Better Finder Rename": https://www.publicspace.net/ABetterFinderRename/index.html
Besides the bug, it's a better practice to have unique filenames anyway, whether achieved in camera or as part of the offload.
(2) Duplicates can happen if drag/dropping projects, clips or multicams between libraries. In some cases the media links can go to the wrong file. The solution is never drag these items "bare" between libraries -- only do so within a transfer event.
Sam Mestman discusses this from 06:30 to 11:00 in the below video, but you may want to watch Sam's whole talk from 02:00 to 11:00. He demonstrates this on a Lumaforge NAS but it's not unique to a NAS.
I don't know why this isn't part of any formal documentation or tutorial.
Thanks Joe. This is one area of FCP X which I am still surprised there's no better handling of keeping libraries and events clean and trim with one iteration of a clip. However I recognize that the metadata for two clips may not be the same as well as the keywords.
I've been using EditReady for a long time for unique nomenclature (which includes the show, episode number, shoot number, card letter (we name ours), camera angle, clip name, and audio incremented number) of all principal photography clips before ingesting into FCP X. I am not a fan of using folders when I don't have to. I like to keep things in the filename to reduce abstraction. Folders can be renamed and moved, etc. Filenames seldom are at the Finder level at least. I used to use Renamer and also have used A Better Finder Renamer, but EditReady filled in the gap for rewrapping and handling the naming as well. Same with KYNO, but unfortunately I've had too many small issues with KYNO to use it fully yet even though it's feature rich.
Also, XML interchange isn't a great workflow if one uses custom (or not) generators with drop zones for media in their projects since XML doesn't support that media. That's too bad, because creating custom generators is a big time saver, but also prevents any reliable use of reconciling external drives with the final project to the master drive from which the media came from reliably. You have to do it all in FCP X by moving, margin, copying events, etc.
I am creating a set of questions and testing them slowly under various scenarios to get a better sense of what FCP X is doing in the background. I'd really like FCP X to have more robust copy/merge features with other options to keep what you want, get rid of what you don't need...in addition to drop zone XML support.
[Tangier Clarke] "I'd really like FCP X to have more robust copy/merge features with other options to keep what you want, get rid of what you don't need.."
Have you looked at Merge X: http://www.merge.software
Merge X cannot yet merge timeline edits, however the developers are working on this. The below video is in Spanish but with English subtitles. The developer discusses this at 11:30: