Renamed Camera Archive Files Won’t Import

[Gerry Fraiberg]

I went back to the Camera Archive through the Finder and returned the clips back to their original names, as shown in the import window. The clips then imported fine.

[Ben Scott]

the other thing to do is right click the camera archive and open package contents, it has the original folder structure

good if you ever needed to get this tapeless media into another editing program

[Gerry Fraiberg]

Thanks, Ben. That’s here I tried to make the name changes. Fortunately I was able to change back to the original names here as well. The Import Camera Archive retained the original file names, so I was able to copy them.

[Bill Davis]

I think this is a good reflection on the difference between Legacy’s “flat file” lookup system and X’s relational database approach.

Since the database in X is tasked with clip management – and since that management is modal (the same clip based metadata can be used for different functions in different areas of the program – the “spider web” of data links can grow rapidly in X as you work.

In a system like this, changing the underlying ID information of an original asset – can cause huge issues since any change has to propagate out to every instance of that’s clips use.

Imagine changing the name (ID TAG) of a basic clip that might be tied to countless color corrections, audio adjustments, buried in dozens of compound clips, and referenced to multiple projects. The potential complexity is kinda staggering.

So X seems happiest when you tag a base level asset and and then leave that alone — so that the database can reliably do it’s work knowing where the fundamental clip assets reside, and what they’re called.

In a “flat file” system where links to a clip are severely limited – changing an assets name is pretty easy. In a relational database like X employs – not so trivial at all, I suspect.

FWIW.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Gerry Fraiberg]

Lesson learned.

[Jeremy Garchow]

I hear you, Bill, but all we would need is permission to tell fcpx, hey, I’m changing that file with this file, get over it and let me reconnect.

As far as the camera archive, only the name was changed, not the contents. So it seems that fcpx only tracks the name of the camera archive, not the contents.

[Bill Davis] “Imagine changing the name (ID TAG) of a basic clip that might be tied to countless color corrections, audio adjustments, buried in dozens of compound clips, and referenced to multiple projects. The potential complexity is kinda staggering. “

The same was true of fcp7. Fcp7 is still a database. If reconnecting and something didn’t match exactly, fcp7 adjusts. The same should be true with X.

My guess is that they haven’t had the time to lock all that down, yet. It would have to be smart enough to leave gaps in primaries if need be. Just like fcpxml doesn’t have position data or audio levels, reconnect isn’t finished yet either.

[Bill Davis]

[Jeremy Garchow] “The same was true of fcp7. Fcp7 is still a database. If reconnecting and something didn’t match exactly, fcp7 adjusts. The same should be true with X.”

Jeremy,

I’m not convinced it’s true in the same way. My thinking is that connections in a flat file database system are constrained to “single state adds” in most cases. In other words, you can link new things to other things easily, but the buck stops when it comes to a change to one thing – rippling down the tree to lots of other things.

That’s kinda what happens in a fully-relational database. The “bi-directional” cross-linking that provides the power – also makes change potentially orders of magnitude more complex.

I might be totally wrong since I’m not a database pro. Just someone who’s had minimal experience building rudimentary databases, largely in Filemaker Pro over it’s evolution. And seen glimpses of how complex things can get when, for example, I changed some “lookup” data and got surprised when ALL the damn numbers changed – including the numbers in the forms that I didn’t WANT them to change in.

It showed me that with the power of relational complexity – comes the need to limit potential conflict.

After all, I don’t want to TINT a scene in Timeline A – only to find that the color change ripples back up to the source clip – then back down to every use of that scene in every project it’s ever appeared in. That’s perfectly possible in a fully relational database, but it’s not the behavior we want or need.

In X, the more sensible structure seems to be employed. Changes made in the Event Browser are “global” and available to all connected timelines – but changes in timelines are specific to that use – and don’t necessarily reflect back to the source clip.

The database “reports” data like clip length to the timeline index. But they seem to be very careful about how they’re implementing the database to timeline relationships so that things stay sensible.

That’s the sense I get anyway.

FWIW.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Jeremy Garchow]

[Bill Davis] “Changes made in the Event Browser are “global” and available to all connected timelines”

But I don’t find this to be true. I change something in the event browser, it does not change it in a Project. If I dupe something in an event, and change the original, what I changed does not effect the dupe. I’m not talking about changes to all the instances of a clip, I’m talking about changing what all those instances point to. There’s evidence that this is possible in the program today. Bring in proxy and high quality media of the same clip, and fcpx can effortlessly switch between the two separate media files with a preference change. Now, just give me control of what is called a proxy and what is called high quality instead of fcpx creating those files for me and locking them out.

FCPX needs to be smart enough to allow adjustment to the media file. Swap one unique ID number with another.

All the filters and level adjustments are stored with their separate instances, just like fcp7.

[Bill Davis]

[Jeremy Garchow] “But I don’t find this to be true. I change something in the event browser, it does not change it in a Project. If I dupe something in an event, and change the original, what I changed does not effect the dupe.”

I agree Jeremy that “change flow” in X is largely contextual.

The sense I’m thinking about is how, if you make a decision to apply IN and OUT points to a clip in the event browser that metadata will persist for that clip in the EB – and is available for the user for re-use in any subsequent use of that clip for any project at any time in the future. It’s “edit once” and use the edit decision everywhere – across all projects – as you like.

Same with keywords. Apply the metadata once – it persists across all subsequent uses of the clip, regardless of how or if it goes into a particular project.

That metadata flows into sub clips, connected clips, project libraries and partially, I think, even into XML exports (tho I haven’t played much with that so it might be limited.)

I agree that everything isn’t free flowing and bi-directional – I think that would be a huge relational mess as I implied in my original post.

The key is to learn how the flow goes (generally from the Event Browser into the Timeline then into the Project Library with an offshoot of the data populating the Timeline index – and exporting via SHARE and XML.

The key is how different this is from Legacy where there was a much more simplistic data flow from Capture scratch to Bins to Timeline – then out. Thinking about how the new Event Library fit into that and building the links between it and the timeline – along with the gutting and re-building away from Quicktime toward AV Foundation and Core technologies ARE the big central changes Apple made to Final Cut.

And its a large enough change that it takes serious getting used to – particularly with legions of Legacy users needing to understand the differences in order to make informed adopt/not adopt decisions.

FWIW.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Jeremy Garchow]

That’s all well and good, Bill, I know what you’re saying, but it really has nothing to do with reconnecting clips.

Yes, fcpx forms new relationships with the footage in the ways you describe, but if it can track multiple copies of footage already, it should at least give us the control to tell it which versions to track.