Rebuilding a project – what’s your strategy?

[Jeremy Garchow]

I guess in this case we are talking about media that is not .mov on import. That is MXF, etc.

Jeremy

[Bill Davis]

Just a few personal thoughts for those who are trying to wrap their heads around how X treats it’s assets that is WAY different from how “flat file” or “lookup” (Capture Scratch type) NLEs…

First, back when I adopted FCP-X, one of the biggest mistakes I made was not understanding that while I was editing I was also building a pretty complex database behind the scenes. The WORST aspect of this is that I look back at the projects I created in my first two months, and I see an absolute MESS of database organization!

I had Events that had content from multiple cards from multiple shoots – Projects with half their content off one Event and half off another (which was fine until I dismounted a project and had half my clips go offline!) and I realized I’d started multiple projects without paying any attention at all to which events they were linked to. It was a NIGHTMARE.

This was part of what drove me to start investigating Disk Images. Disk Images started to make huge sense since if I started ALL projects at square one – Backing up my field shots in an Image – rather than just trying to get clips and projects into a storyline so I could START my work there (a strategy that’s not particularly solid in X!) ,

The Timeline (storyline) in X is NOT the start of your editing. (It’s roughly the THIRD place after the IMPORT transcoding – and EVENT BROWSER organization) It wasn’t until I better understood this that things started to make sense because I was learning how things FIT in the database world of X.

BECAUSE X is database driven – the program essentially is always looking around for fundamental ID tags that it knows what to do with. Disk Images (same as ARCHIVEs inside X) work GREAT for this, because they preserve the deep level ID info that X can locate and work with fast as soon as they are launched on your computer.

As you grow in X, you start to better understand this database process. So it becomes easier to make smart choices about all sorts of issues – like whether to Copy clips INTO X projects, or use Disk Image reference files – or whether or not to do ProRes or Proxy conversions. These issues kinda require you to at least understand where X’s relational database looks for things and how it manages it’s assets.

Over the past year, I’ve often argued strongly about not using the FINDER to move assets – this is fundamentally why. It’s not that finder copying is bad per se, it’s just WAY too easy to break the database links when you work in the Finder with stuff that X has permanent location ID for in it’s database.

This thread seems to me to be largely about that kind of problem. Projects MOVED, but not moved in a way to preserve the links necessary for the X database.

It IS possible to re-link things in X, but it’s NOT as convenient or as easy as just maintaining and managing the original links the program ALWAYS creates as you work.

It’s one of those X differences. The program automatically keeps track of things really, REALLY well. But it only keeps track of them in relation to how YOU set things up.

I screwed up a LOT in my first months and on my first half a dozen projects, because I simply didn’t know any better.

Part of the reality of X.

FWIW.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Jeremy Garchow]

FCPX can create camera archives that solves this kind of problem.

It also creates a walled garden.

I understand your point, Bill, but there are some of us who need more than an FCPX camera archive.

[Bill Davis] “Over the past year, I’ve often argued strongly about not using the FINDER to move assets – this is fundamentally why. It’s not that finder copying is bad per se, it’s just WAY too easy to break the database links when you work in the Finder with stuff that X has permanent location ID for in it’s database.

This thread seems to me to be largely about that kind of problem. Projects MOVED, but not moved in a way to preserve the links necessary for the X database. “

It would be nice to be able to tell FCPX, “hey, I know the media is not there, but it is in fact here”.

This process can and should be better. I’m sure it will get there.

[Bill Davis]

[Jeremy Garchow] “I understand your point, Bill, but there are some of us who need more than an FCPX camera archive.”

I absolutely get this.

I hope that there’s a development path that gets ALL of us agile “off-desktop” media links that let facility editors share and manage central storage. Heck, it would be a good for me as it is for you guys!

I want X to develop “down” (features for consumers such as support for inexpensive heavily compressed camcorder and/or phone generated content) “across” (more features for editors like me in the sweet spot where X works great right now) AND I’d like to see it develop “up” (better features for facilities and post houses)

I can’t really imagine that it won’t develop in all those directions, since with a great core code, working out from such a solid base in different directions has to be easier than just trying to “fix” code that was never built for the future.

Here’s hoping you, me (and the kid having a blast shooting skateboard POV videos with his iPhone!) all get taken care of!

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Tangier Clarke]

Bill and Eugene, thanks for the input. I’m no stranger to dealing with databases (MySQL, Postgre, Access, etc.), so I understand your points Bill about the importance of doing it the FCP X way. It seems like one of the large issues is being able to point FCP X to where the reel(s) resides.

After a shoot, I take the cards (which when mounted on the desktop are all called “Untitled” or No “Name”), create new folders on our backup hard drive(s) with unique consecutive name (per camera if necessary for multicam shoots). These are our backups.

Ex –
projShortName-camX-01
projShortName-camX-02
projShortName-camX-01[H4N Audio]
.
.
. etc

These are the reels on the backup drives I’d want to point FCP X to. This is the media that’s transcoded for editorial and [the transcoded clips] will be deleted once the project is finished and mastered.

Creating those archives, though it works, takes up space, time, etc. And the thought of having to create a finder level archive that isolates Finder folders and elements to FCP X and away from other apps is disconcerting, but it seems necessary. It seems the only other way for other apps to (for example) review content in those archives (assuming the archives replace the original reel backups above, rather than doubling the space taken up) is to first invoke the OS level “Show package contents” or open the archive. Talk about walled garden.

Makes me want a way to make “trick” the OS in to thinking the folders above are archives just by changing the extension on the folder (if there was one) like you would a file such as a word doc, text file, or video file type.

Where’s ResEdit when I need it!

Definitely, If I could just tell FCP X where the reels are without the archiving process that would be ideal. The ID can stay in the event database as it should and content can be reimported and assigned to the same id as long as FCP X checks metadata in the backup against what’s already in the event database so there’s a one to one relationship to what it was on the first import and what it needs to be [again] on any successive import.

Side note: we’re noticing a problem with reimporting that FCP X is having trouble relinking files because the timestamp in FCP X clip name is literally 1 hour off from when the original project was created, so it thinks it’s not the right clip to connect.

Tangier

[Eugeny Korkhin]

I must note that we don’t keep (at least, for now) our assets as fcp archives (walled garden) or images of cards ( I’m a bit paranoid about images – if the image gets corrupted then everything inside is lost). We keep copies of cards in dedicated folders. But i think the reason I could restore the project easily is that we haven’t changed the location of assets since import – they reside on a network backup drive. But, again, in case this drive “goes offline” and we have to use another back up for restore – I expect it to become more than two buttons click as it is now.

[Andreas Kiel]

Just saw this thread by chance.

Here how FCPX works (and I don’t like it):

Once you want to back a project and want to add used clips to the new event you get a new project with a new uid and a new event with a new uid (to avoid collisions).

But if you think that’s a backup you are wrong.
The event finally is a more less empty event which references the original event(s) and the media or media aliases inside this event. So if inside the original media of a referenced event(s) there are aliases the backup only will reference to “an alias of an alias”.

To make a “self contained” backup you have to select the new event and select “Organize Media…” this will copy ALL needed source files into the new event and make into a independent event.
This is not really effective and has nothing to do with a real “Organize Media” but it’s the only way to make a safe backup right now.

If you’re familiar with XML you can take that route to organize the new event.

-Andreas

Spherico
https://www.spherico.com/filmtools