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

  • Bret Williams

    November 5, 2012 at 10:27 pm

    I still don’t get it. An event is akin to an FCP project. It certainly SHOULD take a lot longer to open than a bin. And clicking on another event is essentially the same thing as opening up an additional project in 7. If its a huge project, it’s going to take a long time. Especially if you’re showing thumbnails. If you have it in list view it should open quicker. Just curious, but are you showing filmstrips? I show my events as single thumbnails and I just don’t have any of these complaints. I guess it only has to cache 1 frame per shot. I don’t think skimming requires special caching.

  • Charlie Austin

    November 5, 2012 at 10:36 pm

    [Bret Williams] “I still don’t get it. An event is akin to an FCP project.”

    I think that’s where the disconnect is happening. It seems Oliver may be equating X Events with bins. Which is not the right analogy, and I can see how trying to use X Events as bins would be an enormous clusterfu… well you know… I mean, imagine using MC or FCP 7 projects as bins. Yikes!

    Events=Projects
    Collections=Bins

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

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

  • Aindreas Gallagher

    November 5, 2012 at 11:22 pm

    [Oliver Peters] “the issue with Events is that you cannot organize a set of Events into a folder, since the Event has to exist at the root-level of the drive. (You can do this with Bins in MC or FCP7 or PPro.) That’s unlike Projects, where Project files can be buried into folders and subfolders several deep.”

    Given the lack of in anger usage, I’m not qualified to speak to this, but I kind of instinctively agree that there is an issue with events as the primary spring moving down into exposed semantic tags, over right into the event browser, then being acted upon by calling up a sequence/project.

    basically I think events are too tank like, and fundamentally misfired as primary editing data objects containers – in essence an event is neither, and can be neither, a classical bin within a project super structure, or a classical project containing footage and sequences. In my limited experience, I think the “it gets compound clips” does not answer the issue of a basic hierarchy flaw?
    Fine that its a locked off silo, although thats really not fine – but really what apple are saying is that the primary object, the first thing you call into existence, is a photo bank style archive of material. Not an over arching editing project container. This approach of gunning the photography reels in, as a monolithic block , is true of most photography software, and that is the model Apple have appropriated here.

    but in editing, the primary object is not the specific card banks coming in, or the container they might reside in – the primary object is the client or personally assigned editing goal – that is the entire game – new every time – You name the project with what it is designed to be, and begin assembling the myriad bits of material associated with the overall editorial.

    and so then –

    because the ingest event is the application ceiling, Apple have effectively lopped the head off the editing organisational structure – it is dispersed into undifferentiated events and projects – hence we all get to deactivate events – on a per session basis, in order to try to re-assert basic per project priority.

    To be more plain: everywhere anyone walks into – You have assigned editing objects – but those objects are editorial, narrative, or commercial goals – those are the over riding concern – not the video data containers they might contain. The fact that FCPX cannot configure itself to represent a single goal, as opposed to an archive of events and dispersed editing sequences, means that – and this should come as no surprise to anyone, not alone is FCPX going nowhere, its almost impossible to see how it could ever have gone anywhere. We’re talking an incredibly fundamental flaw in approach no?

    https://vimeo.com/user1590967/videos http://www.ogallchoir.net promo producer/editor.grading/motion graphics

  • Oliver Peters

    November 5, 2012 at 11:25 pm

    [Charlie Austin] “Again.. semantics. X Events are like FCP 7 or MC Projects, not bins.”

    Actually yes and no. From a pure data point-of-view, an FCP 7 project contains all the data, as does an MC bin (not the project) and as does an FCP X Event. So, FCP 7 Project = FCP X Event (or Project) = MC Bin. At the Finder level, each of these constitute individual files that contain all of the relevant data within. In the case of both FCP X and MC, I can move around Event (X), Project (X) and Bin (MC) files independent of the larger production they are part of.

    [Charlie Austin] “KW Collections are the analog to bins.”

    Sort of. They are only analogous to bins (in the application’s use of the term within the UI) if we are restricting that to bins that contain only subclips. Master clips only exist at the Event level. In FCP X, if you trash a Collection, the master clips are still there. In FCP 7 or MC, if you trash a bin and the clips inside, you will have deleted master clips if that’s what was inside.

    But veering back on-topic, the idea that FCP X Events = FCP 7 Projects = MC Bins supports the original notion that I started with. Namely… How is the database structure of X really all that different than what’s come before it? I contend it’s not. Merely that the databasing method is different in the programming sense, but hardly different in any practical way that the user cares about.

    – Oliver

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

  • Richard Herd

    November 5, 2012 at 11:29 pm

    [Oliver Peters] “but hardly different in any practical way that the user cares about”

    One cool exception in X is being able to import finder’s folders as keywords — but of course that’s not really the databasiness — merely practical.

    EDIT: Which means I do a lot of bin editing as finder folders. Folder name “ClientName”; inside there is “audio” | audiofx | score.

    clientname/picture/20121105/filename.mov
    clientname/audio/audiofx/filename.aif
    clientname/audio/score/filename.aif

  • Charlie Austin

    November 5, 2012 at 11:47 pm

    [Oliver Peters]
    Sort of. They are only analogous to bins (in the application’s use of the term within the UI) if we are restricting that to bins that contain only subclips. Master clips only exist at the Event level.

    Well, based on how I organize things, I respectfully disagree. If I get a folder (named Feature) with 6 reels of a feature from a client, and drag that folder onto the event, it creates a Collection (bin… named Feature) which contains all my master clips. The same thing happens if I drag that folder into FCP 7. Now it’s true, since a collection is basically just a user defined sorted view of the event, if I delete the Collection, my master clips still exist in the event but that’s not a bad thing. if i want to delete the actual clips i have to explicitly choose to move them to the trash. From the collection or the event. My point is that Collections are, organizationally, the same as bins. I can put master clips in them, make them show sub clips, whatever. Same thing. What can you not do with a keyword collection that you can do with a bin?

    [Oliver Peters] But veering back on-topic, the idea that FCP X Events = FCP 7 Projects = MC Bins supports the original notion that I started with. Namely… How is the database structure of X really all that different than what’s come before it? I contend it’s not. Merely that the databasing method is different in the programming sense, but hardly different in any practical way that the user cares about.

    I can’t answer that because I’m not a database programmer. All I can tell you is that it is light years easier to sort, find, arrange, categorize, tag, etc. media than in any other NLE I’ve used. If it is in fact the same as everything else, than everyone else needs to step up their game. 🙂

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

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

  • Carsten Orlt

    November 6, 2012 at 12:03 am

    [Aindreas Gallagher] “To be more plain: everywhere anyone walks into – You have assigned editing objects – but those objects are editorial, narrative, or commercial goals – those are the over riding concern – not the video data containers they might contain. The fact that FCPX cannot configure itself to represent a single goal, as opposed to an archive of events and dispersed editing sequences, means that – and this should come as no surprise to anyone, not alone is FCPX going nowhere, its almost impossible to see how it could ever have gone anywhere. We’re talking an incredibly fundamental flaw in approach no?”

    Got to love your lingo, but the only correct part in all of this is the ‘no’ at the end 🙂

  • Walter Soyka

    November 6, 2012 at 12:15 am

    [Andrew Richards] “This is true with respect to single-user desktop NLEs, but there is a lot of upside to FCPX’s use of the Core Data API for multiple-user scenarios, live sharing, etc. I continue to wish for there to be a shared Event database that FCPX can address as a client to enable live sharing of Events, but that seems less and less likely to happen. Flat file datastores cannot permit that kind of granular multi-user transaction, which is why for instance shared bins on Avid Unity are read-only for everyone sharing the bin.”

    Actual flat files with no controlling process mediating access — of course. But a database need not be modeled relationally to be multi-user. A monolithic database with a single table (so frequently derided here as a spreadsheet) could be multi-user if accessed through a database server rather than a database file.

    My point is that there is a lot of red-herring arm waving here about the relational database, and a lot of FCPX functionality that I suspect is incorrectly attributed to relational database model. The “database” part is more important to us in most contexts than the “relational” part.

    Of course there are very good reasons to choose a relational database: constraints (encouraging integrity), normalization (avoiding data duplication), and query simplicity and speed surely factor in here. On to CoreData/SQLite — I think it’s a very good thing for an NLE developer to use a modern, well-featured, robust database engine instead of wasting resources developing their own.

    I’d be very curious about your opinion on SQLite performance at scale. As others in this thread talk about larger numbers of events and projects (with unknown amounts of footage, ranges, and edits), does scalability come into play with SQLite versus other database solutions? How big does the data set have to get before SQLite struggles?

    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

  • Charlie Austin

    November 6, 2012 at 12:32 am

    [Aindreas Gallagher]
    basically I think events are too tank like, and fundamentally misfired as primary editing data objects containers – in essence an event is neither, and can be neither, a classical bin within a project super structure, or a classical project containing footage and sequences.

    Can’t be? The Event is the project. I don’t know what you guys are doing, but I no more look to the Event itself to find my media than I try to see my media by clicking on a projects tab in FCP 7. It’s an object that contains all my media, which i have organized into bins. It just happens to show all the media in the project if I highlight it.

    You’re right that it doesn’t hold sequences, which is a godsend for me as I often have at least 50 sequences in a project, in many cases double that. My project (Event) stays nice and manageable and organized, and my sequences (projects) can multiply like bacteria without cluttering up my Event. And I can keep all those sequences organized very nicely on their own. It makes perfect sense. I friggin hate hunting through every bin in my FCP projects looking for a sequence, expanding folders, opening folders in new tabs that fill up my second monitor, moving windows so I can see the newly opened bin tabs underneath it. You find that conducive to editing?

    [Aindreas Gallagher] but in editing, the primary object is not the specific card banks coming in, or the container they might reside in – the primary object is the client or personally assigned editing goal – that is the entire game – new every time – You name the project with what it is designed to be, and begin assembling the myriad bits of material associated with the overall editorial.

    Yes, as an editor, I do this in FCP X. I could give a shit about the card banks or the container. Are you saying the FCP 7 project isn’t a container? If your point is that the sequences aren’t living in the event then uh… I don’t see how this makes a difference in the creative process. And if you must, you can do all your edits in Compound Clips in the event. Why you’d want to is beyond me, but you can.

    [Aindreas Gallagher] ..because the ingest event is the application ceiling, Apple have effectively lopped the head off the editing organisational structure – it is dispersed into undifferentiated events and projects – hence we all get to deactivate events – on a per session basis, in order to try to re-assert basic per project priority.

    Huh? So you’re telling me that in FCP 7 you never open and close projects? Again… The Event is the project, it’s not undifferentiated, it has a name just like it does in FCP 7. Instead of making a folder in my FCP 7 project called “cuts” and then putting all the sequences in subfolders by name I just put my projects into folders with the same name as the Event in the project library. It’s effectively the same.

    [Aindreas Gallagher] To be more plain: everywhere anyone walks into – You have assigned editing objects – but those objects are editorial, narrative, or commercial goals – those are the over riding concern – not the video data containers they might contain. The fact that FCPX cannot configure itself to represent a single goal, as opposed to an archive of events and dispersed editing sequences, means that – and this should come as no surprise to anyone, not alone is FCPX going nowhere, its almost impossible to see how it could ever have gone anywhere.

    I really have no idea what you’re trying to say here. “cannot configure itself to represent a single goal”? “Dispersed editing sequences”? Every one of my X Events is organized exactly the same as my FCP & projects. Seriously, exactly the same structure, bin (collection) names, everything. My projects (sequences) are organized exactly the same as well, with an added bonus that they have their own library in which i can organize them. I really don’t get all the hand wringing here… There’s a bunch of shit in X that bugs me, but the organizational structure is not one of them. It’s way better than “classic”.

    [Aindreas Gallagher] We’re talking an incredibly fundamental flaw in approach no?”

    No. 🙂

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

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

  • Aindreas Gallagher

    November 6, 2012 at 12:34 am

    nope.

    Come on carsten – lets take the example of commercial work – editing projects are called by specific client briefs – it is a truth in all facilities that there are complex and specific naming conventions for the elements of these campaigns.

    An edit project – a super structure file – a single instance effort that took place and is named specifically, down to number code, that needs to be whole and unto itself, able to be called, in its entirety, months or years after, is brass tacks as a component in that environment.

    You need to be able to call, and dismiss, pretty much the entirety of an editorial effort, by calling a single name/file.

    Not pick though an insane hodgepodge of de-activated event footage archives and projects.

    That hodgepodge is just not on – if you really think through the implications of that FCPX architecture, over time, in a facility, with different freelance operators hitting the same system at different time points.. seriously –

    it’s a bad joke Carsten. It’s beyond ridicule.

    https://vimeo.com/user1590967/videos http://www.ogallchoir.net promo producer/editor.grading/motion graphics

Page 7 of 12

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