Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations FCP X as a database

  • FCP X as a database

    Posted by Oliver Peters on November 4, 2012 at 3:36 pm

    Out of curiosity, for you champions of FCP X as a database…

    How is FCP X any more of a database than Media Composer or Premiere Pro with embedded XMP data? Somehow I simply don’t see that as being true. For example, there is ZERO database functionality outside of the Events currently visible inside FCP X at any given time.

    Furthermore, I see the direction being taken as in direct conflict with how we need to get our work done, since it’s a closed environment, tied to whatever gets exposed in the ever-changing XML. I realize the same issue is there with other apps, but it feels like Apple is trying to do the same thing as they tried with iTunes – namely make it a hub for everything. Not sure it that’s really the best approach.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

    Jeremy Garchow replied 13 years, 6 months ago 17 Members · 116 Replies
  • 116 Replies
  • Craig Seeman

    November 4, 2012 at 4:00 pm

    There’s data and there’s data base. I see most NLEs other NLEs as more of a spreadsheet.

    FCPX is still a maturing data base structure. A lot of the custom info isn’t yet utilized much and a lot of the potential info isn’t yet gathered from the metadata of source files.

    It’s not that other NLEs don’t have some data base functions but that FCPX seems deliberately written to advance on those functions even if not yet fully developed.

    The relationship between Events and Projects, is one example as are keyword collections, smart collections, favorites are another.

    Roles will likely mature as a means of control (my guess of course).

    If I were to critique FCPX’s use of data I’d probably use the analogy (danger Will Robinson) in that it is developing a Filemaker underbelly but currently constricted with a Bento like interface. I don’t think the complex relationships (and by that I mean as a video relational database) are fully exploited as of yet.

    I do think the crux of it is that while NLEs gather data, most are like spreadsheets and FCPX is at least moving towards relational use.

  • Oliver Peters

    November 4, 2012 at 4:48 pm

    [Craig Seeman] “The relationship between Events and Projects”

    In what way is this any different than Avid’s bin structure? Each bin, whether it holds sequences or clips is a separate data file on the hard drive. Plus project media is embedded into the media file format.

    [Craig Seeman] “as are keyword collections, smart collections, favorites are another”

    How is this different than sub clips, custom sift and find functions?

    [Craig Seeman] “in that it is developing a Filemaker underbelly but currently constricted with a Bento like interface”

    That’s probably an apt, yet scary analogy. But these are all relational, in ways that FCP X isn’t. That’s because you have to have every Event and Project online (exposed within FCP X) in order for it to functional like a database any more so than every other NLE. FCP X is not FC Server.

    About the closest we come to something that’s really different is how proxies and original media are handled. Although even that is lifted from Avid.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

  • Craig Seeman

    November 4, 2012 at 5:00 pm

    [Oliver Peters] “How is this different than sub clips, custom sift and find functions?”

    Relationship. The same file can be used in multiple simultaneous “queries” in that it can exist in numerous keyword and smart collections. While you can certainly copy/paste/duplicate a clip or subclip in other NLEs but that to me is akin to copy/paste/duplicate as one would do in a spreadsheet rather than having something being a data point in multiple calculations as one might find in a relational database.

    [Oliver Peters] “FCP X is not FC Server.”

    Just my hunch but I can’t help but believe something like that is going to be coming from someone at some times. I know, not a substantial response but since seeing the Event Project relationship it screams for a management system. Much the reason why I make the Filemaker Bento comment. There’s lots of dada input but the management of it is still spartan.

    [Oliver Peters] “In what way is this any different than Avid’s bin structure?”

    Bins exist in Avid Projects.
    It’s hard to make a direct analogy since they are so radically different.
    In FCPX and Event can be the source media for many Projects Simultaneously.
    A Project can draw from many Events.
    That one can examine a Project and see Referenced Events is an indicator to me the Events and Projects are relationships and not “self contained” as things are in Avid. Again you can “copy” things from Project to Project but as I stated previously, that one must do that reminds me more of a spreadsheet rather than a developed One to Many, Many to One, Many to Many “Relationship” one has in FCPX.

  • Bill Davis

    November 4, 2012 at 7:29 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.

    YMMV.

    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.

  • Oliver Peters

    November 4, 2012 at 9:14 pm

    [Craig Seeman] “While you can certainly copy/paste/duplicate a clip or subclip in other NLEs but that to me is akin to copy/paste/duplicate as one would do in a spreadsheet rather than having something being a data point in multiple calculations as one might find in a relational database.”

    I know everyone is very fond of saying that, but there is no tangible evidence that there actually is any difference. Just a different spin on the same solution. Code-wise, there probably is, but in practical application, there isn’t. In a traditional NLE, if you have multiple subclips based on a master clip, they still all point to the same media file.

    [Craig Seeman] “Event Project relationship it screams for a management system.”

    Absolutely. One of X’s very big weak points. Right now there is no way to effectively manage (within the application) a production that would generate 100 Events and 100 Projects. I don’t mean the software can’t handle it (though I have my doubts) – rather that the interface does not effectively support it for the operator.

    [Craig Seeman] “Bins exist in Avid Projects.”

    Actually no. An Avid Project is really just an umbrella folder with bins files inside. Editors can easily “sneaker net” bin files between each other at the Finder level, exactly like you can with FCP X Project files. Think of an Avid bin as the same as an FCP 7 project file. All of the pertinent metadata resides within the bin file. In fact, that’s basically the way EditShare is able to provide Unity-style project sharing using FCP 7. They treat multiple FCP project files the same as Avid treats bin files. Then they add an umbrella layer to control multiple FCP 7 projects, the same way that an Avid project handles bin files.

    [Craig Seeman] “That one can examine a Project and see Referenced Events is an indicator to me the Events and Projects are relationships and not “self contained” as things are in Avid. “

    The same is true in the Avid world. In fact, you can have Avid media exist without the presence of corresponding projects and the media file retained the info of the associated project it was created under.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

  • Craig Seeman

    November 4, 2012 at 10:02 pm

    [Oliver Peters] “In a traditional NLE, if you have multiple subclips based on a master clip, they still all point to the same media file.”

    And the data used in a spreadsheet could very well be used in a relational database. That the data is there and that it can be used doesn’t equate with how it is actually used.

    A database differs in that it actually handles such relationships. Doing a sort in a spreadsheet is not the same as building queries in a database. FCPX does well within it’s narrow Event/Project relationships. It lakes the “meta” manager though. Hence my Filemaker Bento analogy (although not the most accurate but describes my intent).

    I think some of the database management issues the FCPX developers face are way certain fundamental features have taken so long to develop such as copy paste of individual attributes. My guess is it probably requires a very complex series relationships While the front end expression of that data is no more complex than what exists in other NLEs, the underlying web of relationship probably meant they had a longer and more complex road to get there.

    That FCPX is trackless and rather takes the path that all clips, compound, secondary, all are relational dependencies, unlike independent tracks (much like a spreadsheet) probably creates programming challenges to bring that data out in usable form. It’s something they’re working on (I believe) and the probably a large part of it’s Bento like limitations at the moment. Build the relationships and then they need to build the front end to give the end user control of those relationships.

  • Bret Williams

    November 4, 2012 at 10:11 pm

    Unlike some I’m sorta with you. The Avid bin/project structure is conceptually very similar to X. I feel like the way X manages events vs. Avid bins is a bit better. In Avid, you can open any bin from any project you want. In X, you have access to whatever events are available.

    I don’t feel like there is any grandiose amazing database going on. In fact, events know nothing of projects, and to some extent, projects know nothing of events. For example, a clip in a project has absolutely no knowledge of what keyword collection it came from. All it knows is what event it is in. The event keeps up with all the info on that clip. It makes aliases to the original or points to the proxys, etc. The project knows nothing. It’s insanely simple really. FCP 7 kept up with much much more in it’s timeline. Each clip was tied to a specific clip in a specific bin. As well as being tied to a specific file at a specific location. In fact, legacy could tell you which clips had been used in sequences with a find used command. In X, the even has absolutely no idea if a clip has been used in a project anywhere. It’s pretty much a one way road.

    That said, I think the logging and key wording really is a different concept from traditional bins. I use keywords as bins, but they’re still a bit different. They really are a database. Highlighting multiple keyword collections is basically a search for clips with those keywords. The result is a bin of clips with those keywords. A combined bin. I can’t remember if the Avid superbin was that way, but FCP 7 wasn’t. A clip lived in one bin unless you duplicated it. And there was no master “event” where all the media existed.

  • Charlie Austin

    November 4, 2012 at 10:25 pm

    [Oliver Peters] ” a production that would generate 100 Events and 100 Projects. I don’t mean the software can’t handle it (though I have my doubts) – rather that the interface does not effectively support it for the operator.”

    Not really a reply to the thread topic, but on the above point, the 5 bucks spent on Event Manager makes managing projects and events *way* easier than in FCP 7. And FWIW, I’ve got at least one event that has close to 100 projects (multiple spots with multiple versions) associated with it. The software handles it just fine. It’s trivial to organize projects into Folders/Subfolders in the Project Library, and use Event Manager to open and close whatever is needed.

    Now you could argue that FCP X can’t do it alone, but it;s kind of like complaining about an NLE because it doesn’t have every plug in on earth built in. Some people don’t need to manage huge piles of projects and events. Those that do, buy the add on…

    One more point re: metadata, Roles in particular. I send out OMF’s/AAF’s for post mixing. Due to the nature of the trailer/promo biz, I really don’t have the luxury of being able to take the time to maintain perfectly split audio while I’m cutting. Just cram it wherever it fit.s ‘cuz the client wants to see it *now*. (this is why I don’t miss tracks at all, but that’s another topic…) And since, once again, OMF/AAF export isn’t built into FCP X, I gotta spend some money to get that functionality.

    But… In other NLE’s, I need to spend X amount of time splitting out my tracks before I send it to a mix. In X, since I’ve assigned Roles metadata to my audio – which, BTW, takes way less time than patching tracks and playing track Tetris while I cut – all I need to do is tell X2Pro what order to group my Roles, press a button, and it’s done. Based on my hourly rate, X2Pro on paid for itself after using it twice. And I never have to do splits again. 🙂 *That* is an example of a cool feature of X as a database.

    ————————————————————-

    ~”It is a poor craftsman who blames his tools.”~

  • Oliver Peters

    November 4, 2012 at 10:35 pm

    [Charlie Austin] “Not really a reply to the thread topic, but on the above point, the 5 bucks spent on Event Manager makes managing projects and events *way* easier than in FCP 7. And FWIW, I’ve got at least one event that has close to 100 projects (multiple spots with multiple versions) associated with it. The software handles it just fine. It’s trivial to organize projects into Folders/Subfolders in the Project Library, and use Event Manager to open and close whatever is needed. “

    So how does it handle this when all 100 of each have to be online and accessible? I find that when this is the case, the amount of buffering to RAM that X has to do becomes really cumbersome. So it’s not simply a matter of hiding things in a folder, because when you open it (like projects) it takes a long time. Everything has to be ready and skimmable.

    Event Manager X is fine, but now you are constantly in a situation of exiting and relaunching the app.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

  • Charlie Austin

    November 4, 2012 at 10:38 pm

    [Bret Williams] “In fact, legacy could tell you which clips had been used in sequences with a find used command. In X, the even has absolutely no idea if a clip has been used in a project anywhere. It’s pretty much a one way road.”

    Actually, I’m not sure the event doesn’t know, it’s just that, as Craig has said, the front end to get to that info isn’t there yet. Based on the new compound clip behavior, it’s clearly possible for X to know in what projects an object in an event is used. And changing a “master” CC changes all the instances of it in multiple projects. Maybe they can not only put in a Find in projects command for event clips, but also be able to replace them. … a kid can dream right? 😉

    ————————————————————-

    ~”It is a poor craftsman who blames his tools.”~

Page 1 of 12

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy