APPLE FINAL CUT PRO: Apple Final Cut Pro X FCPX Debates FCP Legacy FCP Tutorials

Re: FCP X as a database

COW Forums : Creative Community Conversations (was FCPX Debates)

Respond to this post   •   Return to posts index   •   Read entire thread

Bill Davis
Re: FCP X as a database
on Nov 4, 2012 at 7:29:01 pm

I also think the only way to view this accurately is to remember that the largest "slam" to X in the early days, is that they completely tore down the existing program to write the new one on a completely different fundamental foundation.

Tearing out Quicktime in favor of AV Foundation and the Core Services idea was, in essence, acknowledging the reality that programming has moved toward modularity over a monolithic "one pile of code" approach.

That new modularity is precisely what I think portends well for the future of the database in X.

Look at the addition of Multi-Cam. The new capabilities are accessed via their own little universe within the software, but they didn't actually CHANGE anything about how the core program operated.

Instead of putting the controls for the the new capabilities IN THE TIMELINE (the old model)- they were able to seamlessly exit you to a workspace for the specialized task (the Angle Editor) and express those results directly back into the same exact timeline you otherwise worked with. Other than some menu command links, there's little to revise in your thinking about the operation of the core software - even to give you a MAJOR new feature.

Same thing with Roles, although there was more "impact" on the timeline with Roles than with Multi-cam - the concept is the same. It's not "change happens when you ADD to the timeline code" as much as it's "build the module then LINK it to the timeline here - here - and here."

This IS the database process. More additive and less "regenerative" to my thinking.

The thing about databases is that once you get the core established - it's probably no more complex to "link" to and from them between flat file and relational approaches - but it's WAY different in terms of their ability to perform well as a databases complexity grows.

So if anyone accepts that the craft of "editing" is growing in complexity in the age of more formats, more feeds, more codecs, more workflows, and more options, then a tool built to handle extra complexity should be welcome.

Those who focus on timeline operations might say NO - my job is simply to edit and I don't care about the before and after stuff. And that's fine. I respect that. If cutting is your focus, you might not really need the rest of these tools.

But if your job stretches beyond the timeline, these new tools look to me to be a HUGE boon as editors in many classes are increasingly asked to generate results outside the timeline - particularly in areas like content distribution.

So if your concept of editing is that it's what happens between one brain and one timeline - or even a small TEAM of brains and one timeline, then flat file or even semi-relational is fine. Particularly if someone ELSE will be taking your work and getting it out to the customers.

OTOH, If your concept of editing includes the need to handle an ever increasing world of differing inputs, bring them all into order in a central location - and export the result to a similarly expanding universe of targets - then putting a basic "database engine" at the center of your program - particularly one that's got the capacity to grow to accommodate complexity - seems pretty smart.

I understand, Oliver why you're asking this. Because at present, the database in X is just largely a "display" system that lets early adopters learn what is essentially the new language of it's operation. It does NOT currently have robust import or export hooks. But if the core is capable. I've got to think those are pretty easy.

So it's a matter of design and intent. These are clues to direction.

X sees a video world of increasing complexity before - possibly during - and definitely AFTER the actual edit - and has built in engine inside the program that has the relational database tools to manage that.

If you think X is already what it always will be - then the database is actually pretty ignorable. One CAN after all, operate X much like Legacy and just focus on the timeline stuff. Kinda like buying a big tool set and only ever using a hammer, a pair of pliers and a couple of screwdrivers out of it.

If that's all you need to do - great. But most people who work want more options for doing more kinds of work. And I think X is built for those people.

But if you think data management and search IS a huge part of the future of visual content creation - then anyone who spends time learning the "peripheral suite" of import, database manipulation, and export — that are arrayed in X around the timeline - are essentially training themselves, more or less - for where the industry might be moving.

Just my opinion.


Know someone who teaches video editing in elementary school, high school or college? Tell them to check out - video editing curriculum complete with licensed practice content.

Posts IndexRead Thread 

Current Message Thread:

© 2020 All Rights Reserved