Renamed Camera Archive Files Won’t Import

[Bill Davis]

[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.”

But Jeremy, isn’t the entire concept of “reconnecting clips” dependent on the database structure? When a clip in legacy had a single clear pathway – from Scratch to Bin to timeline – “reconnect” meant one clear operation. If the path was broken, it was broken in one place ONLY. The link between the Scratch position and the Browser – information there was simply passed along to the timeline consistently – any “missing link” info started at the Capture Scratch – passed through to the Browser (where it was potentially linked to a bin placement, but nothing more) – then to the timeline where the data flow stopped unless you were outputting a final or XML list. The stages upstream didn’t have to keep “track” of anything really. The clips just sat there in an isolated world of timeline position info. It reported out to nothing unless you wanted to generate a “snapshot in time” XML report or save a duplicate of your timeline, but neither the browser, the clip, the bin, nor the timeline had more than very rudimentary communications with anything else, and nothing that was very useful except the XML for round tripping and segmented output for exporting and re-inport of timeline sections.

The foundation of X changes that. In this early stage, we’re given new pipes. The most important is a “report loop” that involves bi-directional communications to and from the Event Browser. Clips land there first. They can be left there without doing anything to them, but if you decide to apply metadata – that information will not only persist for this project, but for all your future projects you want to link to that Event. That’s a BIG fundamental shift in thinking. It’s why editing IN the event browser in X is arguably more powerful than editing was in the timeline in Legacy. The decisions are not just persistent but accessible for any and all subsequent projects where you would like to take advantage of those decisions. Then when you drag your “edited” and “tagged” clips, to the timeline, they carry all the Event Browser metadata AND give you the opportunity to add more metadata that is project specific.

The “issue” with re-connect media. Is that it now has to become a “modal” operation.

If what you’re re-linking is just fixed length video a clip – and the data is a perfect reflection of the original that has become “unlinked” it’s probably not a very big issue. But what if it’s not? What if the element you want to “re-link” is is something like a LOGO? What if your new one is a different size or bit depth, or aspect ratio from the original one? Now the software has to figure out if your intent is to replace not just the timeline occurrence, but occurrences in the EB, and in connections like sub clip relationships and compounds – or if your intent is to re-link to everything – including where that clip resides in the EB – which might, in turn, include effecting changes to other Projects which might have other metadata applied to them.

It just seems to me that when you bring “relationalism” into any database, you’re adding a world of complexity that is very, very useful, but also very finicky.

I can see a situation where the decision to “re-link” a single clip might set off a chain reaction where in order to properly gauge user intent, the only safe thing to do is toss up a host of conditional choices where it somehow lists all projects, timelines, compound clips, and titles that the “re-linked” asset resides in, and asks you to decide whether you want to re-link to all, some (or potentially even none!) of them at this point in your work.

Maybe I’m over-thinkng this. But it just seems to me that in Legacy, “re-linking” was kinda trivial. Connect this to that – everywhere, always- and you’re done.

In the database world of X, it’s a bit more complicated.

But I could certainly be wrong.

Again, thanks for your responses here. It helps greatly to push me to expand my thinking about the X interface and how it “really” works. Something that isn’t always what I expect even now.

Take care.

BTW, Someday I’m going to resurrect that Taxonomy group idea. I’d love to do it, it’s just that all my historical client seem to have been kissed by princes/princesses and they’re all suddenly calling for work. No complaints, but it’s been limiting on how much time I can spend here. I greatly enjoy the debate, but work is work.

“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] “The foundation of X changes that. In this early stage, we’re given new pipes. The most important is a “report loop” that involves bi-directional communications to and from the Event Browser. Clips land there first. They can be left there without doing anything to them, but if you decide to apply metadata – that information will not only persist for this project, but for all your future projects you want to link to that Event. That’s a BIG fundamental shift in thinking. It’s why editing IN the event browser in X is arguably more powerful than editing was in the timeline in Legacy. The decisions are not just persistent but accessible for any and all subsequent projects where you would like to take advantage of those decisions. Then when you drag your “edited” and “tagged” clips, to the timeline, they carry all the Event Browser metadata AND give you the opportunity to add more metadata that is project specific. “

Not really though, Bill. Yes, there are more ways to divide, describe and use that clip in the browser, but ALL of hat information is connected to that one singular clip. If you change and move all of that data, the clip does not change. All we need fcpx to be ale to do, is use a different clip. It can do it already with the Proxy and high quality files, and then throw in the original files. The capability is there, don’t you see? Fcpx wouldn’t let you connect without the same name, and would throw warnings about other mismatching attributes. Why can’t fcpx do it?

[Bill Davis] “If what you’re re-linking is just fixed length video a clip – and the data is a perfect reflection of the original that has become “unlinked” it’s probably not a very big issue. But what if it’s not? What if the element you want to “re-link” is is something like a LOGO? What if your new one is a different size or bit depth, or aspect ratio from the original one? Now the software has to figure out if your intent is to replace not just the timeline occurrence, but occurrences in the EB, and in connections like sub clip relationships and compounds – or if your intent is to re-link to everything – including where that clip resides in the EB – which might, in turn, include effecting changes to other Projects which might have other metadata applied to them.”

This is the same with fcp7, Bill. A piece of media is a piece of media. If it changes, it will change wherever that piece of media is located in Events, Projects, or fcp7. Metadata is Event, Project, or project specific. In the case of reconnect, there are times when I want to connect to a completely new piece of media (conform). This means all these other Events and Projects you mention will keep the relationship to the old media. We are professionals, we can handle it. If I write over a file, it is intentional. In the case of Gerry, the o.p., he didn’t even change anything except a name of the container. X should be able to figure this out, and my guess is that some day it will be capable.

[Bill Davis] “I can see a situation where the decision to “re-link” a single clip might set off a chain reaction where in order to properly gauge user intent, the only safe thing to do is toss up a host of conditional choices where it somehow lists all projects, timelines, compound clips, and titles that the “re-linked” asset resides in, and asks you to decide whether you want to re-link to all, some (or potentially even none!) of them at this point in your work.”

Why? I am telling it to relink in this Project, and that’s all it needs to know. I am telling it to relink in this Event, the rest of the events will stay linked to the original. This isn’t any different to fcp7 with projects, timelines, nests and media. Fcp7 is still a database.

[Bill Davis] “Maybe I’m over-thinkng this. But it just seems to me that in Legacy, “re-linking” was kinda trivial. Connect this to that – everywhere, always- and you’re done.”

there’s no question that some things are more “complicated” in X, but having an option to reconnect should be there, and it won’t break anything. Usually, reconnect is an action of intent, I think X needs this. For now, it’s still rather closed as most of the time, x disconnects things that you didn’t mean to and won’t let you get them back. It’s silly.

Thank you, for the discussion as well.

Jeremy