-
Range-based keywording: unique to FCP X?
-
[Richard Herd] “Anyway, we also need a way to export keywords into an index file.”
Agreed 100%. Metadata portability would open up all kinds of new workflows for FCPX users.
[Richard Herd] “If I’m looking for a particular piece of footage, I want X to tell me its own Drive_A then I can plug it in and get the footage.”
FCPX is Digital Asset Management Lite. Full-fledged DAMs can track offline/proxy assets to allow users to manage massive data sets. This would be an important feature to add sometime in the future. The current all-online, all-the-time model isn’t sustainable.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Richard Herd] “If I’m looking for a particular piece of footage, I want X to tell me its own Drive_A then I can plug it in and get the footage.”
Just curious, do you (did you) do this with FCP7?
-
Not exactly. I used tape name.
-
[Richard Herd] “Not exactly. I used tape name.”
Got ya.
Hopefully, FCPXML will support more metadata in the future. At that point, you could get some sort of parser to find any information on your Events/Projects, but you would have to have added that data (it’s sometimes added depending on the import format/technique), and remembered to have exported an XML before the job is taken offline.
-
[Richard Herd] ” If I’m looking for a particular piece of footage, I want X to tell me its own Drive_A then I can plug it in and get the footage. “
This gets so frustrating after a while.
That’s NOT how X is designed, Richard. What you’re describing is how Legacy was designed.
Back then, our Capture Scratches were simple folders of clips and all that was required was a pointer in the software to the location. So storing clips in separate places off-line and connecting to them to the editor made perfect sense. Where you stored them and how you named them and whether you moved them somewhere else or not was trivial. Just update the connection info and keep moving.
In X, the Project Library the Event Browser and the Timeline are always connected – for extremely valid reasons that provided a lot more power and flexibility – once you become accustomed to it. The cost for that is that you can’t just move stuff willy nilly. So instead of loading up “clips” you load up whole PROJECTS – and the expectation is that ALL the clips for that project will be in fixed locations and dependably accessible for X. You shouldn’t really ever have to go looking for them, because they’ll already be there – embedded in the fabric of the project database.
And this (along with a lot of other new thinking) has been a major hurdle to all those who spent truly significant time operating any traditional NLE interface before migrating to X. This program is fundamentally different. It’s built on different ideas and different ways of defining tasks. And if you approach it with anything but an open mind – willing to re-think how things might function – you’ll be running up against walls unnecessarily, IMO.
Blow “I need to connect clips” out of your thinking if you want to operate efficiently in X.
Substitute “‘I need to build a reliable database of all my assets – so I can access and use ANY of those assets – across any and all present and future projects.”
The joy is that in the new system – anything (edit decisions, color correction, audio levels – you apply to your captured assets in the Event Browser – remain available for use in all subsequent projects. So you’re building a persistent body of assets “as you like them” as you operate X. The database of your edit decisions grows and grows and makes you life easier and easier the longer you work in X.
When legacy was born, storage was expensive and computers were slower. Today, storage is cheap and computers and networks are ever faster. X is building toward that future. All your past editing decisions – preserved – constantly on – and available to you to use or modify as you like.
So hopefully “where’s that clip so I can link to it” will be completely unnecessary in the future X is building towards – because it will always be right where it’s always been – connected to your editing system.
Ready when you need it.
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
-
[Bill Davis] “That’s NOT how X is designed, Richard. What you’re describing is how Legacy was designed.
“Then it’s poor design. Avid media is handled by a database too, and it can generate detailed reports of your sequence and bins showing you where that footage lives. What’s the point of having a database with all of this information being tracked by the software if it’s being held hostage by that same software? This is exactly what these databases are good for – tracking assets and giving that information to the editor.
[Bill Davis] “So hopefully “where’s that clip so I can link to it” will be completely unnecessary in the future X is building towards – because it will always be right where it’s always been – connected to your editing system. “
So all projects have to be online all the time? Even for a one man shop that’s silly. When I was the only production guy at a small ad agency I would work on 20+ clients in a year, complete hundreds of commercials/videos, and generate terabytes of footage. Having to keep all of that online all the time because my software won’t share information with me isn’t good. This should be addressed by Apple. It’s a reasonable and logical feature request.
—————-
Michael Hancock
Editor -
You’ve got it all wrong. Some drives fill up, but they still have footage on them. I want X to tell me the name of the drive and what is on it. Basic database stuff.
-
[Michael Hancock] “[Bill Davis] “That’s NOT how X is designed, Richard. What you’re describing is how Legacy was designed.
”Then it’s poor design.”
Everyone calm down, we know that FCPX is not up to potential yet. FCPXML doesn’t carry this information yet. As soon as it does, you will be able to port more information in and out of FCPX.
Jeremy
-
[Richard Herd] “You’ve got it all wrong. Some drives fill up, but they still have footage on them. I want X to tell me the name of the drive and what is on it. Basic database stuff.”
If the Event is online, then you simply look at FCPX and it will tell you what drive it’s on.
Maybe I’m missing something?
-
[Bill Davis] “That’s NOT how X is designed, Richard. What you’re describing is how Legacy was designed. “
I disagree. FCP was not a DAM. It didn’t track metadata like FCPX does. These questions around asset management are new to most of us, unless you were using CatDV, FCSvr, or the like.
[Bill Davis] “When legacy was born, storage was expensive and computers were slower. Today, storage is cheap and computers and networks are ever faster. X is building toward that future. All your past editing decisions – preserved – constantly on – and available to you to use or modify as you like.”
Soyka’s Law — Expectations rise at the same rate as capabilities. Applied here, storage is cheaper, but files are bigger.
With respect to its DAM, FCPX’s current design simply doesn’t scale. That’s not forward-thinking design. It’s either bad design — or it’s completely immature.
I have 24 TB of storage online, and it’s not nearly to hold all my work. I have a dozen or so 1.5 TB LTO5 tapes holding archives. Keeping all media for all projects from all time online isn’t practical for everyone. Building the storage infrastructure would be mind-boggling complicated and expensive.
Jeremy seems to have a lot of confidence that future updates to FCPXML will allow third parties to deal with this. I’d love to see that, and I think that third-party developers are offering some really innovating solutions (like VirtualMXF), but I also think that splitting DAM duties between FCPX and a third-party app reduces the power of having a DAM in an NLE in the first place.
I hope that this is an area that Apple intends to develop themselves in the future, because this is one of those maddening close-but-not-quite features.
We discussed this a couple months ago [link]. Here’s what I wrote then:
IBM sees three dimensions to Big Data [link]: volume, velocity, and variety.
Volume means we’re amassing more data than ever before. Velocity means we’re amassing it faster. Variety means our data is not all neatly structured as an individual datum we can stuff in a spreadsheet or database; assets like text, graphics, audio and video are totally unstructured.
FCPX starts to treat variety, creating some structures that the user can apply to their unstructured data. However, as long as this is a manual process for humans, the twin threats of volume and velocity threaten to overwhelm our ability to keep up on variety.
I suppose you could argue that FCPX is starting to treat velocity, with native format support, but that’s still far from perfect [link].
FCPX offers no tools at all for managing volume.
You wrote a great line about FCPX and metadata a couple months ago:
[Bill Davis] “And what sets X apart from the competition? The elevation of data handling into a role arguably equal to image manipulation.”
I think this is true, but Apple needs to push very, very hard to make sure that the tools they’re providing for data handling are as suitable to the task as the tools for image manipulation.
If metadata is going to be a true advantage for Apple and for FCPX in ongoing projects versus one-offs, they must really innovate that toolset.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events
Reply to this Discussion! Login or Sign Up