Alias into the FCP X Library Top-Level?

Here’s what I’d like to see FCP X do, but it doesn’t yet do:

1. Capture live event in ProRes Via Media Express to “XsanVolume/CaptureFolder”
2. Open FCP X Library “XsanVolume/FCP X Libraries/TargetLibrary” and create a new event for captured footage.
3. Import clip from “XsanVolume/CaptureFolder” into “XsanVolume/FCP X Libraries/TargetLibrary” – FCP X should hard-link to the footage that already exists on the volume, which would take microseconds. This saves time and storage space.
4. Delete file from source folder
5. Begin rendering waveforms & thumbnails
6. Edit


Here’s what really happens doing this task with FCP X’s current workflow:

1. Capture live event in ProRes Via Media Express to “XsanVolume/CaptureFolder”
2. Open FCP X Library “XsanVolume/FCP X Libraries/TargetLibrary” and create a new library for captured event.
3. Import clip from “XsanVolume/CaptureFolder” into “XsanVolume/FCP X Libraries/TargetLibrary” – FCP X begins to copy & duplicate source clip despite the clip being on the same volume. (or does this on consolidate)
4. Begin rendering waveforms & thumbnails
5. Edit



FCP X *should* always hard-link to media that is on the same volume as the target Library. But it doesn’t. If it did, I wouldn’t’ have to do this manually. What FCP X currently does—whether you alias-import as external media and consolidate later or not—is duplicate the imported file(s). If your clips are humongoid as our live events are, this takes a considerable amount of time and wasted storage.

The advantage of having everything contained inside a targeted event is that when I need to delete the event, I don’t have to go hunting for all no-longer-needed assets. They’re inside the event. Just trash the event.

You are missing a very important point here: if the media is hard linked to the event, as you wish to have, and you delete the event, the media will NOT be deleted!
That is because if you hard link the media will be referenced in 2 places (namely the capture folder and the event); only when both references are removed will the actual disk space be freed.

So you end up having to delete from the capture folder anyway. The solution seems obvious to me from the start - external media...

True. I failed to include the step where I delete the original location after hard-link import, leaving only one reference to the file inside the library to be deleted at a later date.

External media is not a solution for this case. It's too messy. I want our capture folder free of footage which has already been imported into a working library. if it's in the capture folder then to our editors, it means that the footage hasn't been imported yet and the person responsible for that footage still needs to address it, so no one else touches it.

This is for sure a shared Xsan volume. Leaving source files littered all over the volume is a horrible workflow as no one has time to go hunting for assets to delete or archive when they are no longer needed. Organization is already a huge problem with shared media because no one knows if they can delete footage or not because it may be in use by someone else's project. Keeping all assets within FCP X libraries makes lots of sense organizational-wise because when a Library or event is done, it's easy to delete or archive as needed. It's a lot cleaner process. We're in a very lengthly transition to all-inclusive Libraries, but I believe it will make things easier for all of us in the long term.

If you are using shared storage where multiple people will have to get at the same media, you should probably be using external media, which brings the workflow very close to how you would do things in FCP7. You should do the media organization on the finder level before bringing it in with 'leave in place.' In your case, you can have subfolders for each event, and when you want to delete the event, you will have to take the extra step and delete that folder in the finder afterward also. I don't see how that can be harder than trying to manually manage aliases while mucking around in the libraries.

For your workflow, it would go something like this:
1) Ingest media into a centralized space.
2) Move the media for an event into its own subfolder somewhere else (a folder structure for your project).
3) Import that folder into its own event by 'leaving in place' the media.

If you're organized on the finder level with a folder for each event, it shouldn't be too hard to know which ones you can delete.

Using external media in a shared environment has a lot of advantages because it's easier to move small libraries around and you don't have to worry about wasting space by duplicating media in multiple libraries. If what you're doing works for you, then that's ok I suppose, but almost every place I know that uses shared storage and multiple editors will use externally managed media.

As far as archiving, you can consolidate on an event-by-event basis, so in case you are using media for all over the place, you can consolidate at the end so that it will copy ONLY the media that you have cherry-picked from elsewhere. We do this with sound effects for example, because we keep all sounds in a centralized volume that you can mount. We'll have an event just for audio, which we'll pull from this volume. But when it comes time to archive the project, we will consolidate that event and it will copy all the files into our project folder. In the end, everything for a project will live in this folder, and that's all we have to archive.

"I don't want to leave the footage in the capture folder, I want it inside a specified event within the Library."

"But it's still vastly more efficient to get the result I want. The file never gets copied to a local drive, it stays on Xsan – the same exact volume – just a different effective location."

OK, I'm confused, there seems to be contradictions every time someone offers a solution. I'm very confused as to what you're doing.

Leave In Place makes aliases in nothing flat. Copy to Event makes a copy as fast as any other method. You have one or the other. I'm totally confused. How does manually making aliases speed things up?

"FCP X *should* always hard-link to media that is on the same volume as the target Library. But it doesn’t."

Actually, it does, on the same volume, make a hard link. But not when going from the XSAN to your local drive.

You guys need a Digital Asset Management system that works with FCPX, for sure. CatDV would be a great starting place...

Ryan,

Though I meanwhile understand your idea I think it's a bad bad idea cause as mentioned before it's not really a good idea to do some things inside a fcpbundle. It's not a good approach as it takes too many steps which can lead to confusion and bad organization.

You can create an Automator script which allows you to select files (limited to the capture folder), create a new folder ("MyLiveEvent") on the SAN , inside that one a new folder ("MyMedia") and move by script the selected files into this one. It's a matter of parts of a second.
Start working with a new library inside "MyLiveEvent" and import all media from "MyMedia" leaving files in place.
After finishing just delete the "MyLiveEvent" folder from the SAN.

- Andreas

I was a little slow getting to this, but did a quick n dirty screen capture of what I'm getting every time I import a file into FCPX sourced from the same volume, so you can see it firsthand.

If I understand what you guys are saying, this shouldn't be happening. But his result is the only result i've ever seen. Now this isn't showing my whole workflow, the point is just to demonstrate what I get when I import from the same volume that the target library resides on. Then I show the workaround I came up with, more or less, because the way FCP X imports in this case aggravates me to no end. I just got sick of it.

Now before anyone tries to gotcha-nit-pick, yes I copied this file for the demo off an SSD, into the a folder on the volume for the purposes of this demo—which I say again, is only to focus on the way FCP X handles this kind of import—and is not what I typically do when the source is via a different volume/camera/etc. Much of the time we capture our primary recording directly onto that same Xsan volume which we edit from, and so of course we'd want to import from that source. The vid effectively shows what happens when we do so.

The file is 75MB, in a .zip. about a 1:30 long.
www.dropbox.com/s/03vz103undxhuko/Workfl...capture.mov.zip?dl=0