-
FCP X as a database
-
[Carsten Orlt] “Could you give an example where you need 100 Events and 100 Projects? “
One example would be a feature film. I realize it’s been said many times that X may not be ready for a film, but the same process applies elsewhere. For example, if you use a separate Event for each camera and each shoot day. A 30-day shoot with 3 cameras would generate 90 Events. I am currently working on a commercial job shot in 6 days with 4 cameras in Media Composer. If this were in X with separate Events, then this little job would generate 24 Events.
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.
As far as Projects, on a feature, you might opt to cut one Project per scene and then combine scenes into Reels and then Reels into the full film. And no, Compound Clips are not a good strategy here. A feature film with a 100 scenes might result in 150-200 Projects (timelines) once you have a few different versions of some of them.
On this little commercial job it’s organized into “selects” sequences. There’s one per camera, plus numerous others for shot types. Then various versions of the edit. So, at least 20-30. Selects sequences are better for this client to assess the material than Smart Collections. Even if I had these organized into Smart and/or Keyword Collections, I would still have to put them on a timeline, so it doesn’t answer the original issues of dealing with a large number of sequences.
Working in this large of a job creates some logical issues in how you navigate the interface, simply because the interface itself has not been designed very well with this in mind. There are a number of poor and counter-intuitive design choices. For example, if you are playing an Event clip and hit the Home key, most NLEs take you back to the start of that clip. In X, the Home key takes you to the top of the loaded Events. That becomes a major annoyance when you have this many Events or even a lot of Collections.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Jeremy Garchow] “That’s a rather broad generalization, don’t you think? I take my job seriously, and throwing more disconnected tools at me does not make feel any better.”
Of course it is! That’s would these threads are all about 😉 But the point is not “disconnected” tools, but rather symbiotic tools. Like FC Studio or CS6. The latter still needs work, but it’s a good direction. But if you are going that route as a developer, you have to learn how to play well with others. Simply tossing out a new interchange format like FCP X XML, with the attitude that others should support it, does us no favors.
[Jeremy Garchow] “I thought one of the cons of FCPX was it’s reliance on third party helpers. Now you are saying that’s what people want? Or are you saying, Apple (or any company) must build an NLE, a DAW, a grading system, a compression application, a compositor, and perhaps some sort of media asset manager all as separate entities with various levels of integration and non integration?”
I’m saying Apple should learn to be part of a larger community and take responsibility for those interchange tools. It’s a process that served them quite well with FC Studio and helped them compared with Avid. Now they’ve basically taken over the role of being the proprietary leader. We are all only willing to deal with it because their version of proprietary is somewhat more “open” and “ubiquitous” than that of others.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Andrew Richards] “In practical terms, there is little to differentiate FCPX’s SQLite-based Events and Projects from the flat-file methods employed by its peers. I’m still waiting to see more of Final Cut Server’s DNA emerge in FCPX’s feature set. I’m not holding my breath though.”
Yet that doesn’t stop a good number of posters from breathlessly marveling at the awesome power of the FCPX Database (with a capital D) or gushing about the wonders of the relational database model.
Jeremy has pointed out how FCP 7 became The Legend of FCP. I think “the database” is the legend of FCPX. Depending on the conversation, the database is either the suggested reason for hope of development of any number of very cool features yet to come, or the suggested cause of difficulty for providing any number of very cool features not here yet.
The data store itself is not as important as what the developers choose to store in it, what methods they provide within the application for accessing and manipulating that data, and what interchange they provide for third parties to access and manipulate that data.
With that mini-rant out of the way, FCPX does do a lot right on the logging/tagging/organization side, in my opinion, by focusing on dynamic data and adopting a bit of the Gmail-style “search, don’t sort” philosophy. Internal database model aside, FCPX is putting some unique data-driven tools in front of its users.
I share the opinion here that there’s a bit of a divide between events and projects in this data-centric orientation. I’m very curious to see if that will be bridged over future releases, or if that separation is by design. I also think there’s a lot of potential for cool data-driven timeline-side tools.
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 -
[Oliver Peters] “One example would be a feature film. I realize it’s been said many times that X may not be ready for a film”
I’ve edited a feature on it so have others, it wasn’t any more problematic than with FCS
[Oliver Peters] “For example, if you use a separate Event for each camera and each shoot day. A 30-day shoot with 3 cameras would generate 90 Events.”
I’m curious, why would you have a separate event for each camera?
[Oliver Peters] “As far as Projects, on a feature, you might opt to cut one Project per scene and then combine scenes into Reels and then Reels into the full film. And no, Compound Clips are not a good strategy here. A feature film with a 100 scenes might result in 150-200 Projects (timelines) once you have a few different versions of some of them.”
Why aren’t compounds a good strategy? Since they have been “fixed” in 10.06 I have been using them as “sequences” with no issues.
Steve Connor
‘It’s just my opinion, with an occasional fact thrown in for good measure” -
[Steve Connor] “I’m curious, why would you have a separate event for each camera?”
Just to clarify, that isn’t necessarily my own strategy. It is, however, one option and what many would logically choose. For example, if you wanted to use Event Manager X to reduce the number of open Events, it would be easier to split Events by camera. Let’s say you wanted to concentrate on editing one scene in a movie for today’s workload, you might opt to only deal with the media shot for that scene. In that case, breaking up the footage into separate Events would facilitate this in a way that’s better than having everything in one huge Event.
[Steve Connor] “Why aren’t compounds a good strategy? Since they have been “fixed” in 10.06 I have been using them as “sequences” with no issues.”
I mean that operationally it’s not a good strategy. Not how the program handles it related to bloat. If I combine scenes into a reel from separate timelines, I still want all clips visible and exposed in the reel’s timeline. That’s because I will still make tweaks throughout all the scenes within and where one scene joins another. I don’t find it particularly practical to constantly step into a Compound Clip to make adjustments now that I’m at the reel level.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Craig Seeman] “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.”
Huh?
FCPX can obviously read these attributes for any given clip (it must, to display them in the UI and to pass them to the renderer), and FCPX can obviously apply these attributes to any given clip (it must, in order for the user to manipulate them via the UI).
The idea of incorporating CoreData is to abstract data storage away from the application. Why would selective attribute copy and paste be any harder whether it’s backed by a relational database or a flat file database?
(And not that it matters, but do we even know if the timeline itself is modeled relationally?)
All that aside, copying and pasting attributes statically across timeline objects isn’t a very dynamic or data-driven approach. How about adding a role-like ability to group objects in a timeline via metadata and apply the same attributes across the set?
Of course, this may become a bit of a conceptual challenge (How do you indicate linked/shared attributes in the UI? How do you best manage changes to these linked/shared attributes? How do you apply the attributes in cases where base assumptions change from item to item [like applying scale to items with different raster sizes]?), but wouldn’t that feel a bit more like the FCPX way?
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 -
It’s pretty obvious, and I’ve seen no example otherwise, that projects simply link to instances in an event. If you change something in an event, it doesn’t change anything in a project. You open the project, and it checks every clip in the event to make sure it’s online and still matches the criteria that it thinks (frame rate, etc.). If it doesn’t, it becomes unrendered.
If you make something a compound clip, it places the cclip in the event and the project places a link to the compound clip in the event. There’s no amazing magic going on.
If the event is going to write something to the project, it would only be able to do it if the project is online. Since you can take events and projects offline without affecting or damaging either, I don’t think the app is even attempting to do this. When a project is offline, the event doesn’t know where it is. And when an event is offline the project doesn’t know where it is. It just knows it needs an event. You can look and see what events are associated with a project. But you can’t see what projects are associated with an event. The event doesn’t know. It can’t know. It could be associated with a thousand projects that are either offline or deleted. It wouldn’t be very useful info.
-
In Avid you can only have one project open. However you could have 100 sequences in that project. But just like FCP 7, I just don’t see any app performing that well with all that stuff cached up. It’s just not feasible. And what would one do in 7? Open a hundred tabs? Any project that starts drawing on that many past projects would be a monster in any edit suite.
I think really FCP X needs to bring it’s own project and event manager into the fold so that it can search them even when they’re not offline. Like EventManager X, but with much more functionality. Perhaps the event manager could even retain the thumbnails or a filmstrip screen shot of sorts, without actually caching any media. Or at most creating some sort of small sized representative video clip proxy. THAT would be pretty powerful. You could preview and/or search events and projects before bringing them online. Perhaps they’re leaving that functionality for another server type companion app.
-
[Bret Williams] “In Avid you can only have one project open. However you could have 100 sequences in that project.”
You can also open any bin from any other Avid project on the system, without the need to specifically open that project. This is the Avid equivalent to FCP7’s ability to have more than one project open.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Oliver Peters] “Just to clarify, that isn’t necessarily my own strategy. It is, however, one option and what many would logically choose. For example, if you wanted to use Event Manager X to reduce the number of open Events, it would be easier to split Events by camera. Let’s say you wanted to concentrate on editing one scene in a movie for today’s workload, you might opt to only deal with the media shot for that scene. In that case, breaking up the footage into separate Events would facilitate this in a way that’s better than having everything in one huge Event.”
I don’t see that logical at all. The event is the encompassing folder. You make sub-folders within the event. It is more akin to a project in FCP 7. It holds all the media and bins. So, just like in any other NLE you can make separate projects all you want, but just know that it increases organizational difficulties. But if a feature film requires multiple events and project, then event manager X (or some computer 101 manipulation in the finder) should solve it no problem. People complain that some sort of project and event handling should be built in and you shouldn’t have to go to the finder. But in FCP legacy you managed your whole project in the finder. You told FCP to save it somewhere, and you had to know where it was to open it again. You could open multiple projects, but then you have to manually keep up with what scratch disk you’re capturing to and rendering to by hand since scratch disk prefs weren’t lodged in the project file. I just don’t see how anyone can complain about the project and event management in X compared to legacy. In X it actually manages where the media is captured and rendered and keeps it all applied to the correct project or event. You can organize projects in the app, in the finder, or with a third party app. There’s no chance of accidentally capturing project A into project B’s capture scratch folder just because both projects are open. There’s no chance of rendering sequence A from project A into Project B’s render folder. It all just works and it’s light years ahead of the non existent management we had in 7. I think everyone just became an expert at manipulating legacy’s shortcomings and now they’re confused as to why the app would actually have a mechanism for doing it itself.
Reply to this Discussion! Login or Sign Up