FORUMS: list search recent posts

FCP X as a database

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Oliver Peters
FCP X as a database
on Nov 4, 2012 at 3:36:48 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


Return to posts index

Craig Seeman
Re: FCP X as a database
on Nov 4, 2012 at 4:00:13 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.


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 4, 2012 at 4:48:41 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


Return to posts index


Craig Seeman
Re: FCP X as a database
on Nov 4, 2012 at 5:00:49 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.



Return to posts index

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.

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.


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 4, 2012 at 9:14:13 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


Return to posts index


Craig Seeman
Re: FCP X as a database
on Nov 4, 2012 at 10:02:11 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.



Return to posts index

Walter Soyka
Re: FCP X as a database
on Nov 5, 2012 at 3:48:37 pm

[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


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 4, 2012 at 10:11:39 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.


Return to posts index


Charlie Austin
Re: FCP X as a database
on Nov 4, 2012 at 10:38:54 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."~


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 12:46:30 am

No, changing a master shot CC in an event doesn't change anything at all in a project. The project is linked to the master event file. You open the project and the project looks at all the master clips in the event. If they've been transcoded or switched to proxys, it doesn't matter. It links to the event, the event keeps track of the media.


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 12:59:59 am

[Bret Williams] "No, changing a master shot CC in an event doesn't change anything at all in a project. The project is linked to the master event file. You open the project and the project looks at all the master clips in the event. If they've been transcoded or switched to proxys, it doesn't matter. It links to the event, the event keeps track of the media."

I hear ya, but changing the contents of an Event CC changes all instances of that object wherever it's used right? At least it's supposed to in 10.0.6, I haven't played with that yet. Maybe it is just a one way Project to Event link, but who knows? It just seems to me that the "in what projects is this clip used" info exists somewhere in the Event database, at least if the project is open. And if it does, maybe it'll be accessible at some point. Or not... ;-)

-------------------------------------------------------------


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


Return to posts index


Bill Davis
Re: FCP X as a database
on Nov 5, 2012 at 1:33:57 am

I think this is what Phil Hodgetts was trying to get through to me when we talked a lot back in the early days when he was trying to impress on me the importance of metadata "flow" in X. Attributes have a directional flow. From import to the EB, then from the EB into Story lines - and from story lines into the project library.

The further upstream you append metadata the more it's available for being "handed off" to later processes. So work done in the EB will always feed your projects - where you have the option to strip and change things by removing or appending new metadata to the incoming files.

I think we're starting to see some conditional data flow back from the project level to the Event Browser (at least as stored compound clip states) but it's always going to be limited unless we want the central database to get REALLY complex - having to constantly not just watch for metadata changes flowing downstream - but tracking the users state changes upstream as well.

FWIW.

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.


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 4:06:19 pm

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.


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 4, 2012 at 10:25:55 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."~


Return to posts index


Oliver Peters
Re: FCP X as a database
on Nov 4, 2012 at 10:35:53 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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 4, 2012 at 11:04:36 pm

[Oliver Peters] "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.

Well, YMMV, but in my case X handles it just fine. I agree about the time it takes to load project film strips in the Library... to an extent. But I actually find that it's gotten much faster with 10.0.6. And, once they're open they're open. On a slightly related note... They do need to work on the whole timeline browser back/forward button thing. It gets a little weird sometimes... ;-)

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

True, but opening X takes no time at all really, at least compared to 7 and, in my limited recent experience, MC and Pr as well. And to me, it's much easier to organize giant piles of projects in multiple folders separate from the Event(s) they reference.

In 7, I have projects that take forever to open because they have so many sequences in them. So I have to duplicate the project, trash all the stuff I hopefully won't need, and move on. Leaving me with 2 or more projects to hunt through if I find I need something old.

And by hunt through, I mean like maybe I had cut a specific shot or little sequence into a spot . 3 months later, I need to find it. In 7, i need to not only find the project version the sequence is in, but if I can't remember which of the multiple versions of multiple spots it's in, I need to open them all one by one 'til I find it. In X, just skim through them in the Library. For me, that's faster and easier...

-------------------------------------------------------------


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


Return to posts index

Chris Harlan
Re: FCP X as a database
on Nov 4, 2012 at 11:58:19 pm

[Oliver Peters] "[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."


The bin structure, btw, is on of the things I'm really digging about MC. I love the way I can move bins between projects, and that the bin retains its own identity. I'm really appreciating the whole notion of a bin as a unit that transcends a project.


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 4, 2012 at 11:44:51 pm

[Oliver Peters] "Not sure it that's really the best approach."

Why?


Return to posts index

David Lawrence
Re: FCP X as a database
on Nov 5, 2012 at 2:05:44 am

[Oliver Peters] "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."

[Jeremy Garchow] "Why?"

Bloat and proprietary vendor lock-in for starters, maybe?

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 5, 2012 at 2:19:31 am

[David Lawrence] "Bloat and proprietary vendor lock-in for starters, maybe?"

Bloat...I think that's been solved, time to move forward.

Almost all NLEs are proprietary. Can you explain what you mean here?

I agree with Oliver that all NLEs are databases, I am just curious as to why it's all of a sudden a bad idea to make an NLE a hub. Isn't that what everyone was so pissed about on day 1? You couldn't get data in or out of it?


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 2:45:47 am

[Jeremy Garchow] "I agree with Oliver that all NLEs are databases, I am just curious as to why it's all of a sudden a bad idea to make an NLE a hub."

I just feel that the iTunes approach involves a walled garden mentality where one application is trying to perform all functions and in the end does most of it badly. For the most part, users who are serious about what they do, don't want a single all-encompassing application and will tend to opt for a suite of compatible, companion tools. Along those same lines, I have no interest is seeing Resolve add more edit-system-style features either.

- Oliver

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


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 5, 2012 at 3:45:51 am

[Oliver Peters] "I just feel that the iTunes approach involves a walled garden mentality where one application is trying to perform all functions and in the end does most of it badly. For the most part, users who are serious about what they do, don't want a single all-encompassing application and will tend to opt for a suite of compatible, companion tools. "

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.

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?

What suite of tools are you talking about? The Creative Suite? Final Cut Studio? Where does something like Autodesk Smoke fit in to this?

Are you saying FCPX is trying to be an "all-in-one"?


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 1:40:37 pm

[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


Return to posts index

Bill Davis
Re: FCP X as a database
on Nov 5, 2012 at 7:24:03 pm

[Oliver Peters] "I'm saying Apple should learn to be part of a larger community and take responsibility for those interchange tools. "

All I can think about is how many times people looked at my original Mac and asked me... "but is it MS-DOS compatible?"

If Apple had even TRIED to make it so - it would have KILLED everything that's come along since.

Compatibility presumes compatibility with what HAS been. That's great if all you want is to have your existing needs met.

Some companies, and Apple notoriously shines here, do actually ask if there's a better way to do things.

Thank goodness.

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.


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 6, 2012 at 3:19:32 am

[Oliver Peters] " Simply tossing out a new interchange format like FCP X XML, with the attitude that others should support it, does us no favors."

Totally. We should be able to use Dynamic Link everywhere.

Oh wait. It's proprietary.

[Oliver Peters] "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."

We've talked about this before. I think Apple develops as much as they need to do and then they SDK the rest.

It allows them more focus, it gives users more options and potentially better support via third party, and Apple gets the benefit of developer feedback.


Return to posts index

Carsten Orlt
Re: FCP X as a database
on Nov 5, 2012 at 4:32:29 am

I think FCPx is doing the exact opposite of what you think it is doing.

It think it actually concentrates on the editing part of post and leaves colour correction/special fx/CGI and sound post to others.
It has both sections but in a basic form which will satisfy 90% of the market today and it has XML to talk to the rest for the 10% who need external solutions to finish their film.

Rather clever on Apples' part to stop trying to turn out a new software every 5 minutes like Adobe does to address a niche section of the whole post market.

Avid tried the same as Adobe by buying a lot of companies and it didn't work (in my eyes).

Anyhow call other NLE's organising inner worlds what you want, FCPx new way of organising footage is for me the best I ever used. I do long form projects and understand if you do short form stuff it might not be that obvious, but for long form un-scripted work it is god-send. Plus the incredible ease and quality of the picture engine makes it a joy to work with. It's not the only software that can combine images to make a film, but it is a very nice one indeed. And I'm not missing anything since leaving FCP7.

[Oliver Peters] "For the most part, users who are serious about what they do, don't want a single all-encompassing application and will tend to opt for a suite of compatible, companion tools."

I sometimes fall into the same trap so: we All shouldn't assume what the 'majority' wants by going by our own preferences. We are passionate and would like to convince everybody about our point of view. After all that is the reason we're on the 'debate' forum. But I for instance I'm very serious about what I do and hate application suites with a passion :-))

What I want is not for one company to make all different post applications. I want each company to concentrate on one section and find the best solution. One company making all will always want you to stay within the fence. If all you make is one aspect you WILL make it talk to others, or make other be able to talk to you if you're confident enough that they will want to play with you.

I think Sony with Sound Forge and Autodesk Smoke are clear indications that Apple will not return any high-end FX (beyond Motion) or audio editing applications. My prediction is: iMovie and FCPx for editing, Motion for graphic design (no need for a smaller sister as it is only $50 and home movies don't need it), Garageband and Logic for Music, iPhoto and Aperture for photos, and that's it.

Happy editing, whatever the tool.


Return to posts index

David Lawrence
Re: FCP X as a database
on Nov 5, 2012 at 2:47:43 am

[Jeremy Garchow] "Bloat...I think that's been solved, time to move forward."

Bloat with compound clips has been solved well. I'm talking about this:

[Oliver Peters] "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."

I think there's a potential bloat problem with the event and project library databases in situations like Oliver describes. What's the largest number of projects you've had in a library? How was the load performance? I'm curious because I even though I only have a handful of simple test projects, my project library load time is not great.

[Jeremy Garchow] "I am just curious as to why it's all of a sudden a bad idea to make an NLE a hub. Isn't that what everyone was so pissed about on day 1? You couldn't get data in or out of it?"

Can you get tags and keyword collections out of it?

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Carsten Orlt
Re: FCP X as a database
on Nov 5, 2012 at 3:54:00 am

[David Lawrence] "[Oliver Peters] "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.""

Could you give an example where you need 100 Events and 100 Projects?

[David Lawrence] "[Jeremy Garchow] "I am just curious as to why it's all of a sudden a bad idea to make an NLE a hub. Isn't that what everyone was so pissed about on day 1? You couldn't get data in or out of it?"

Can you get tags and keyword collections out of it?"


Yes you can. Look and the new Share tab in the Events section (next to Info).


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 5, 2012 at 4:10:08 am

[Carsten Orlt] "Could you give an example where you need 100 Events and 100 Projects? "

A news organization?

Political campaign?

Sports?

Anything with giant swaths of media that extend over days/months/decades?


Return to posts index

Carsten Orlt
Re: FCP X as a database
on Nov 5, 2012 at 4:42:12 am

[Jeremy Garchow] "A news organization?

Political campaign?

Sports?

Anything with giant swaths of media that extend over days/months/decades?"


And what would be the reason that I couldn't add media to a smaller amount of Events in each of those cases?

If I know that having many Events open might cause problem, why would I do it? Wouldn't I use Events differently and reorganise so I use less Events? The only reason to have a separate Event is actually when you want to use media in this Events in more than one Project over a longer period (Archive footage).
And don't confuse this with wanting to make many Projects from one Event.

It does take a different way of organisation. :-) And sometime only to avoid hangs or crashes. All software does that to you....


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 5, 2012 at 12:47:36 pm

[Carsten Orlt] "And what would be the reason that I couldn't add media to a smaller amount of Events in each of those cases?
"


No reason. I was just throwing out hypotheticals as was Oliver.

I'm not saying you should load 100 Projects/Events, but that won't stop people from trying.

I could also see large establishments that want everything online as it is an inherent advantage in X (although Oliver seems to be saying that X handles this badly).

Jeremy


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 4:26:23 pm

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.


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 4:29:59 pm

[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


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 1:31:08 pm

[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


Return to posts index

Steve Connor
Re: FCP X as a database
on Nov 5, 2012 at 1:55:17 pm

[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"


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 2:14:40 pm

[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


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 5:01:40 pm

[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.


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 5:11:40 pm

[Bret Williams] " 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."

Agreed. I really don't get why folks thing the event/project management in X is somehow inferior to that of 7. It's just different. It's like saying I don't like new cars because I can't manually advance the spark and adjust the choke when I start it. And it shifts for me? ;-)

-------------------------------------------------------------


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


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 6:21:44 pm

[Bret Williams] "The event is the encompassing folder. You make sub-folders within the event. "

No. You can make folders within an Event that holds Collections. You can't simply move clips from the main Event into ONLY the folder. That's a lot different than organizing clips within Bins and Folders inside FCP 7 or MC. Correct me if I'm missing something.

- Oliver

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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 6:56:41 pm

[Oliver Peters] "You can't simply move clips from the main Event into ONLY the folder. That's a lot different than organizing clips within Bins and Folders inside FCP 7 or MC. Correct me if I'm missing something."

This may or may not address this, but I rarely look at what's in the event. Everything goes into folders or collections(bins) within the event. I look at the Event sort of like the project tab in fcp 7, it just tells me what "project" I'm working on. Unlike 7 I can highlight it and see/search everything in it, but I never use it for editing... FWIW... here's a couple screenshots... my events library from a "project" I just finished up, and the project library with one folder open. All the other folders have on average about the same amount of projects in them. Sorry it's so long, but you get the idea...



-------------------------------------------------------------


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


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 7:07:47 pm

[Charlie Austin] "This may or may not address this,"

Yes, I understand how to organize in the Event browser, too. Collections are simply like Bins/Folders of sub clips. It's not the same. The clip in now duplicated in the main Event as well as numerous Collections. Plus the more clips you have in an Event, the longer it takes to open and update changes within the session. Even in your screen grab you are showing 3 Events.

- Oliver

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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 7:31:04 pm

[Oliver Peters] "Yes, I understand how to organize in the Event browser, too. Collections are simply like Bins/Folders of sub clips. It's not the same. The clip in now duplicated in the main Event as well as numerous Collections. Plus the more clips you have in an Event, the longer it takes to open and update changes within the session. Even in your screen grab you are showing 3 Events.
"


It was absolutely not my intent to imply you didn't know how to organize things, I just posted that because it's exactly how i would have organized it in FCP 7. Same with the amount of Events. I always have my FX and MX projects open in 7, in addition to whatever project(s) I'm working on.

I really don't see how it's any different at all, other than the way it looks and what things are called, and the fact that the actual event can be selected to list everything that's in it. In 7 it would just be a tab. I guess it's probably a workflow thing... I never make sub clips or sequences of selects in FCP7, just shitloads of markers in my source.

With X I can work the same way, but also mark favorite ranges which effectively makes sub clips for me, which I can view if i want to. So... for me, it's way more efficient. I also have to disagree about the load time. It really doesn't take long at all. The events load way faster than projects in FCP 7. In fact the FX Event was exported from FCP 7, and loads about 3 times faster in X on the same machine. The projects take a little longer to load, but it's not really much worse than if they were all in an FCP7 project when it was loading. YMMV... :-)

-------------------------------------------------------------


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


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 7:42:01 pm

[Charlie Austin] "It was absolutely not my intent to imply you didn't know how to organize things, I just posted that because it's exactly how i would have organized it in FCP 7."

No problem. I didn't mean that you had. In re-reading my response, I guess it sounded harsher than I meant. We're cool.

[Charlie Austin] "With X I can work the same way, but also mark favorite ranges which effectively makes sub clips for me, which I can view if i want to. So... for me, it's way more efficient. I also have to disagree about the load time. It really doesn't take long at all. The events load way faster than projects in FCP 7."

I get what you are saying and don't disagree. I work differently in X than I do in other NLEs. Some good, some bad from my POV. As far as multiple Events, I was merely expanding on ways that it made sense. In fact, ways that seem to coincide with Apple's ideas for why they named it "Events" (and not Bins) in the first place. ;-)

- Oliver

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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 8:02:46 pm

[Oliver Peters] "No problem. I didn't mean that you had. In re-reading my response, I guess it sounded harsher than I meant. We're cool.

Phew... I hate to think I come across as a jerk... unless I'm trying to. lol

[Oliver Peters] ... I work differently in X than I do in other NLEs. Some good, some bad from my POV. As far as multiple Events, I was merely expanding on ways that it made sense. In fact, ways that seem to coincide with Apple's ideas for why they named it "Events" (and not Bins) in the first place. ;-)"

Yeah, I started out trying to work exactly the same in X as i did in FCP7. And it mostly worked. I'm now at the point where I'm starting to try and work the "X way" for lack of a better term. Sometimes i really like it, and sometimes it drives me batshit crazy... but usually because of stuff that lacks polish or doesn't work quite right yet, or because I'm used to doing stuff in a way that's different... not because of how it works... if that makes sense. Also, I equate collections to bins and events to projects. So I can have as many "bins" in a "project" as i want, just as I'm used to doing... Semantics right? -edit: FWIW, I don't import anything into my events once I've created them. I make a bunch of keyword collections (bins) and drag stuff from the finder into the collections. The fact that those clips all show up in the Event as well is an afterthought...

Other than that... color code-able/group-able Roles, match frame replace Edits, maybe some sort of Z-Index for video clips so they'll stay put when compositing and I'm a happy camper. I mean, there's a lot more I'd like to see added and or improved/fixed, to me that's all just icing on the cake... But again... that's just me and how I work. ;-)

-------------------------------------------------------------


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


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 8:44:04 pm

[Charlie Austin] "FWIW, I don't import anything into my events once I've created them. I make a bunch of keyword collections (bins) and drag stuff from the finder into the collections. The fact that those clips all show up in the Event as well is an afterthought...
"


That's exactly what I do, except I usually don't even create the keyword collections. They're usually already on my drive as folders like BRoll, Graphics, AE renders, Camera 1, Camera 2, etc. Then I might make some more keyword collections as things progress.

But the whole thing just makes more sense. Heck, in FCP legacy, you could delete all the clips from your bins and the timeline would still work. I wonder what happens in X? That would be interesting. Would answer some of those link questions earlier...


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 9:22:39 pm

[Bret Williams] "Heck, in FCP legacy, you could delete all the clips from your bins and the timeline would still work. I wonder what happens in X? That would be interesting. Would answer some of those link questions earlier..."

Here's what happens. LOL

It warns you...


and then...


Undo fixes it...

-------------------------------------------------------------


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


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 8:38:05 pm

So I don't get the gripe. In legacy, it took forever to open projects if you had a lot of bins and media. But you probably wouldn't have had multiple projects for a film. Or perhaps you would. So, no different here. If you wanted to have multiple events (like I've said, they're more like a legacy project than a X project is - event is the new project and project sort of a new sequence) you could. And to put it all together in the end, in FCP 7 you'd have to open multiple projects, and in X you'd have to mount multiple events. I don't really see much difference logistically between the two, except that X gives you more options for keeping track of projects than 7, which had none.


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 8:46:40 pm

[Bret Williams] "So I don't get the gripe."

It's an issue of the design of the UI, not the actual functionality. In the hypothetical 100 Events, there is no way to group them within the UI itself. You cannot place them into folders and tuck them out of the way, like you can bins in a single FCP 7 or MC project. Thus you end up wading through them to find the one you need.

And yes, each large Event *IS* slower to open than a bin inside FCP 7 (once the project is open) because the clips all have to be populated with thumbnail and waveform links, even when in the list view. The difference is that in FCP 7 or MC, the slowness only happens once at the start of the session. With FCP X it occurs DURING the session at any time you first click on an Event for the first time after opening the app.

- Oliver

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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 9:06:12 pm

[Oliver Peters] "You cannot place them into folders and tuck them out of the way, like you can bins in a single FCP 7 or MC project. Thus you end up wading through them to find the one you need."

Again.. semantics. X Events are like FCP 7 or MC Projects, not bins. You can open 100 projects in 7 or MC, well, in 7 you can... ;-) but you can't tuck 100 projects into a folder in the UI right? KW Collections are the analog to bins. And you can stuff them into folders or subfolders or whatever you like inside the Event (the object formerly known as Project) ;-)

-------------------------------------------------------------


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


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 11:25:41 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


Return to posts index

Richard Herd
Re: FCP X as a database
on Nov 5, 2012 at 11:29:28 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


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 6, 2012 at 8:04:08 pm

It's interesting to note that over the years, I've come to make my finder folder match my bins exactly. I don't do subclips. Not never, but hardly ever. But if I did I'd make a folder in legacy that says sub clips, and then have sub folders under that so they stand out as something different.

Drives me a little batty when someone gives me a project with everything organized by scenes, but there's no master folders matching up with the folders on the hard drive. Makes it a little difficult to ascertain if everything has been imported.

Now in X, now matter what you drag in and where, it only allows one instance of the clip. Yes it can appear in multiple keyword collections, but there is only one instance. Drag it again it just replaces.

Jeremy pointed out recently that if a clip is offline, you can just drag it in again (with option?) and it relinks. None of the crazy relinking dialog necessary. About time!


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 11:47:48 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."~


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 6, 2012 at 10:12:28 pm

[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 thought the topic was really how you felt in some way that FCP X's use of events and projects was in some way inferior to FCP 7 or MC. What we're trying to do is demonstrate that not only is it just different, it is far superior, especially to FCP 7, which I thought everyone agreed with back in 2001, was complete crap the way bins were integrated into a project. Most of us were coming from Avid back then and realized immediately how silly that was. Then upon realizing how silly it was that scratch disk settings were saved with the application, not the user (remember user settings? that's something Avid has over us) that being able to open multiple projects at once was actually more of a liability than helpful, especially if it was an intern or a producer or your boss in there mucking about with no knowledge of where the assets should go.


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 10:27:11 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.


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 10:36:08 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."~


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 5, 2012 at 7:02:16 pm

[Bret Williams] "There's no chance of accidentally capturing project A into project B's capture scratch folder just because both projects are open."

Actually that's not true. Aside from the fact that you can't "capture" at all unless you are using FW-based cameras or decks, it is possible to import media into the wrong event. If you have a Coke and a Pepsi Event - both visible - it is indeed possible to import Coke media into the Pepsi Event and the other way around. In fact, I contend it is MUCH easier to do in X than it is in 7, IF you set up your drive correctly in 7 in the first place.

Part of what Apple TRIED to do with the design of X was eliminate the editor having to understand the media location structure. They apparently had to field a lot of user problem support calls with 7 because of that issue.

- Oliver

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


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 5, 2012 at 8:56:49 pm

I feel the complete opposite for most imports. If you import something into the wrong event in X, its nobody's fault but your own. I drag from a folder on my drive to an event in the event window (or a keyword collection in the event.) If I drag to the wrong event, well, duh, oops, my bad.

And yes, nobody captures anymore from tape, but we do import/transcode camera archives and I guess you could do the same thing if you had the wrong event highlighted when you pressed cmd+i. But given that in X you only have one event window at a time (something I'd like changed btw) it's a bit harder to do even that. In 7, you could have 5 projects open, but you only point to a set location for capture and render. On my home system, it's all the same pegasus raid, so if I capture to the wrong project, it's just moving some files. But at one facility I work at, it's a media grid system. Each project has a number an that number corresponds to a virtual drive of the same name. So if you're working in 7 on more than one project at a time, you need to be mindful of where your renders are going. If you render to the wrong drive, and then someone else picks up that project later in another room, the renders aren't there

So it's just different, but for the way I work it seems to be much more error proof than legacy ever was for media.


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 6, 2012 at 2:55:50 am

[Oliver Peters] " They apparently had to field a lot of user problem support calls with 7 because of that issue."

Boggles the brain really. The event and project structure is real close to what you find in the Finder and its all in one place.



fcxp_projectlibrary.png



finder.png


Return to posts index

Aindreas Gallagher
Re: FCP X as a database
on Nov 5, 2012 at 11:22:21 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?

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


Return to posts index

Carsten Orlt
Re: FCP X as a database
on Nov 6, 2012 at 12:03:01 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 :-)


Return to posts index

Aindreas Gallagher
Re: FCP X as a database
on Nov 6, 2012 at 12:34:50 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.

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


Return to posts index

Carsten Orlt
Re: FCP X as a database
on Nov 6, 2012 at 2:06:10 am

Come on Aindreas, it can't be that hard :-)

Read Charlie's post below and all is explained. You're creating walls were there aren't any.

Only thing that is different really is that sequences are now outside the initial Event, formerly called Project.

Actually replace the word Event by Project and Keyword by Bin and be done with it. But this would actually use limiting language on a structure that is far more powerful than your 'single file' world.

Happy editing


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 6, 2012 at 2:16:52 am

[Aindreas Gallagher] "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."


Why pick through a hodgepodge? I may be missing something here, but just consolidate your cryptically named project(s) with their associated cryptically named event(s), including all the media or just the clips you've used, stick the newly created project and event folders onto a Disk Image, give it the same cryptic single alphanumeric name, and stick it on your tape drive.

In the distant future, teleport or ride your hovercraft to the Bureau of Archives, find it, open it, and pick up where you left off. The only thing missing in X's consolidation routine vs. classic, is the ability to add some handles to your trimmed media if you choose that option. My guess is it won't always be missing... There's probably a way to do it with XML too, but you'd have to have all the media accessible somewhere...

-------------------------------------------------------------


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


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 6, 2012 at 6:49:11 pm

Wow, uh no. One of the most idiotic things about FCP 1-7 was that in order to access media from another project, was that you had to access THAT project. Then potentially capturing to that project, or screwing up that project, or having just to OPEN that huge project. Media should be separate from projects. And one could argue that Avid has a slight edge in the way they do it in that bins are grouped and stored in general with a particular project, but can be opened within any project. Avid makes sure you can only have one project open, so the nature to screw up another project by opening one of it's bins doesn't exist.

But X takes it one step better I think by separating the two (you could of course archive an event and a proejct together on a drive assuming you have some basic understanding of the finder) so that footage can be grouped by project (just name the event the same as the project, duh) or can be more like the photography motif you're getting at. Kinda depends on what you're doing.

For example, when I worked at Georgia Tech some 19 years ago, we shot and logged sports footage 3-4 days a week. No clue what or when or where or how it was going to be used. We used the videocube FYI. We created bins for the sports and sorted clips by game and date, etc. There were no projects at all on the videocube. Just sequences and bins. You had to do your own organization at the finder. So what we were doing was exactly like the event structure, just not as searchable.

It all seems pretty basic, simple, powerful and extensible. The only thing I might ask for is some sort of an event and project manager built in so that they can be mounted and unmounted without an add-on app. And Oliver makes a good point in that it would be extremely useful to have events be grouped into at least "virtual" folders for obvious organizational reasons and benefits.

I'm completley utterly right, no? :)


Return to posts index

Aindreas Gallagher
Re: FCP X as a database
on Nov 6, 2012 at 7:53:40 pm

yes you are. there.

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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 6, 2012 at 12:32:15 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."~


Return to posts index

Bret Williams
Re: FCP X as a database
on Nov 6, 2012 at 6:52:33 pm

This thread is awesome. You rock. Someone wants to change the name of this away from "the debate" to just FCP X. Have they lost their mind?


Return to posts index

Aindreas Gallagher
Re: FCP X as a database
on Nov 6, 2012 at 11:15:23 pm

look -I'll go with some of this, with massive caveats:

Oliver Peters is making, to my reading, some pretty heavy points above, about the load issue with FCPX in complex projects where the component parts are distributed between projects and events - but. Charlie -

You cannot deny that you are in a different house now

[Charlie Austin] "Can't be? The Event is the project."

so thats wrong.
the event is a declared point of footage call (or is it?). Given that multiple event calls may occur over even say a ten day commercial project, are you willing to flow them into a single event, or do you begin to produce multiple events to delineate significantly different material? Is it event worthy? or do you try to hive it into tags?

Follow me here: Events are a little too important, and they don't do quite enough. And yet there is nothing beyond or above them.
forget that we can make disk images externally to cobble the parts of a given piece together (which is a hack)

the problem here is that there is nothing to intellectually hold those events, that will arise, together within FCPX. they are all just stars on the far right.

FCPX, as an editing system, simply lacks an editing project organisational transparency layer for the editor who might walk into it freelance.

How. In the everliving hell. Does no one see. this?

If I walk in to refine a five month old ad at a facility, and like a photo archive, there are seven or eight odd events open in FCPX from the last guy, what exactly in the hell are my instructions? are they finder instructions? What folders am I moving? Not alone am I being asked to say mount an event and its bits and pieces from a disk image, am I to also deactivate the previous evenings events and projects? Or is that the other guys job? given that the app functions as a bloody photo style archive?

This system as an editing system needs to be able to call and reconfigure its elements (that is to say call and negate all projects and call and negate all events) at the behest of a client specific number coded application call.

because right now its like saying we should all edit in one guy's copy of itunes. where we deactivate playlists, or photo archives or something.

my point is that - if FCPX cannot assemble an externally identifiable project file - then FCPX needs to be able to completely swop out all of its events and projects instantaneously, at some kind of externally driven command.

or we just accept that its a pretty hilarious/horrible misfire going nowhere - and go about our other business.

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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 7, 2012 at 12:44:37 am

[Aindreas Gallagher] "You cannot deny that you are in a different house now

I'll give ya that... it's a nice new house. ;-) Needs some finish work, but it's quite comfortable. lol

[Aindreas Gallagher] ... Given that multiple event calls may occur over even say a ten day commercial project, are you willing to flow them into a single event, or do you begin to produce multiple events to delineate significantly different material? Is it event worthy? or do you try to hive it into tags?

Of course I'd flow them into an Individual event, just as I'd put them all into an individual FCP 7 project. What I'm trying to understand, is why you feel that an Event needs to act any differently than an FCP 7 project. Let's leave MC and Pr aside here, since both you and I are (I think) mostly coming from FCP 7. Take your example above. Why do you feel that you would need to have multiple event calls for this hypothetical project?

If I was cutting this in 7, I'd just make a Project, and start organizing my footage within it. Create some folders, Day 1, Day 2, etc, maybe put subfolders in each folder, A Cam, B Cam, Second Unit... whatever. As media came in I'd either import it to the project and then drop it in the proper folder, or just drag from the Finder. Then I'd create a Cuts bin, put a sequence in it, and start cutting. Not make 10 separate FCP 7 projects, 1 for each days shoot, that would be retar.. uh, dumb right?

I'd do the exact same thing in X... Create an Event, Make some folders in the Event- Day 1, Day 2, etc. In each folder I'd create collections -A Cam, B Cam, Second Unit etc As media came in I'd either import it to the project and then drop it on the proper collection, or just drag from the Finder. Exactly the same. There's no reason to organize anything differently than FCP 7, it's all semantics. Everything lives in one Event. OK, not everything. The sequences live in their own space.

For those I just make a new X project, create a folder in the project library with the same name as the event, put the project in it, and start cutting, organizing different versions into subfolders etc, exactly as I do in 7. The only difference is that all my cuts live in a separate folder, one separate folder... which as i've opined before, is a good thing

[Aindreas Gallagher] Follow me here: Events are a little too important, and they don't do quite enough. And yet there is nothing beyond or above them.
forget that we can make disk images externally to cobble the parts of a given piece together (which is a hack)

the problem here is that there is nothing to intellectually hold those events, that will arise, together within FCPX. they are all just stars on the far right.


Again, I really think that you're visualizing Events the wrong way. Forget disk images for now, I only brought them up earlier as an idea for archiving stuff, though they obviously are being used to manage events. And I must add that I use Event Manager, which makes things a whole lot simpler than it was even with FCP 7, where I had to hunt around in a folder full of projects to open what i want, assuming I didn't accidentally save it to the wrong place, which never happens right? ;-) Apple should buy it and bundle it with the app or fold the functionality into X. But if you, or anyone for that matter, are messing around with X it'll be the best $5 you ever spent. Anyway...

If Events are just stars on the far right, then FCP 7 projects are just a bunch of tabs at the top of a window. You seem to be thinking of X Events as being analogous to the bins (folders) inside an FCP 7 Project , which they are not. I can create one Event for one job, no matter how much different footage, audio, graphics etc I have for that job. Just like an FCP 7 project, it all goes into, and is organized, in the single event. And all the sequences (projects) associated with that Event go in a single project folder with the the same name as the event (fwiw, I add "cuts" to the name). So, yes, i have to open 2 things instead of 1, but really, it's not a big deal, especially with Event Manager.

[Aindreas Gallagher] FCPX, as an editing system, simply lacks an editing project organisational transparency layer for the editor who might walk into it freelance....

...If I walk in to refine a five month old ad at a facility, and like a photo archive, there are seven or eight odd events open in FCPX from the last guy, what exactly in the hell are my instructions? are they finder instructions? What folders am I moving? ...

This system as an editing system needs to be able to call and reconfigure its elements (that is to say call and negate all projects and call and negate all events) at the behest of a client specific number coded application call....

...FCPX needs to be able to completely swop out all of its events and projects instantaneously, at some kind of externally driven command.


Well, you'd be in the same boat if you walked into an FCP 7 shop with no instructions and were presented with a finder folder full of dozens of cryptically named projects, but I get what you're saying here. My response is... you can do all that. Get Event Manager. It addresses every concern you just expressed. Seriously. Tick the boxes for the event and it's associated project folder, press a button, done. Of course you could argue that that should be built into or bundled with X. I agree. And there are probably a lot of people who don't need or care about that but as a pro, I need it. So I bought it.

C'mon man, it's 5 bucks... I thought you were British, not a Scot. ;-)

-------------------------------------------------------------


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


Return to posts index

Aindreas Gallagher
Re: FCP X as a database
on Nov 8, 2012 at 1:36:40 am

[Charlie Austin] "Get Event Manager. It addresses every concern you just expressed. Seriously. Tick the boxes for the event and it's associated project folder, press a button, done. Of course you could argue that that should be built into or bundled with X. I agree."

agreed - but there are a lot of serious perception issues with the software - primary among them being that it is designed out of the guts of single operator persistent noodling software like iphoto/aperture. Software that greets you with all the things you have ever done. In its basic nature, it's inarguable that FCPX looks to do this. It loads all events by default. No one ever asks why iphoto or itunes load all photo collections or playlists by default. And no one has ever tried to sell itunes playlistX manager.

All the approaches you suggest - like hodgett's many diligently worked fixes to the software io and management, function - but apple need, at a minimum, to begin make a clear case for its usability in professional scenarios - after stealing event manager, apple, somewhere on their website, need to begin to make Germanically clear workflow arguments. Adobe are about to play a massive card with anywhere - and avid are a perilously small company, leaking money.

It entirely depends on how much Apple care: as to how much they are willing to reset themselves to the market, given that, in monthly wage terms, the market we represent doesn't buy them a packet of gum.

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


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 7, 2012 at 3:24:30 am

[Aindreas Gallagher] "If I walk in to refine a five month old ad at a facility, and like a photo archive, there are seven or eight odd events open in FCPX from the last guy, what exactly in the hell are my instructions? are they finder instructions? What folders am I moving? Not alone am I being asked to say mount an event and its bits and pieces from a disk image, am I to also deactivate the previous evenings events and projects? Or is that the other guys job? given that the app functions as a bloody photo style archive?"

Eh, f*ck. This is getting crazy. All of this makes more sense if you actually know how to use the program and have actually tried to send something to someone else. It clicks. Really fast.

FCP7 projects can be just as messy, but there's one caveat, that bin structure is fixed. Not so in FCPX. You can keep another editors keyword collections and start your own all over very easily, very quickly, and most importantly non destructively, except for those g*d damn PIOPs which have seriously destroyed a good system, especially when using other people's projects.

Just because the ever loving program doesn't spread sh*t around like FCP7, doesn't make it any worse.

The Events are tidy packages, they are REALLY easy to follow. They work the exact same way on every FCPX install, you put them in the right folder and the bloody things mount. Every time.

You take them out, and they don't mount. Every time.

You don't have to open a project, search for media spread out all over only the original editor knows where.

If working with aliased Events, there are really easy tools to make the Events "self contained".

At some point, you have to stand up, grab your testovaries, and declare yourself a professional and that includes handing off a project in a way that the next guy/gal can handle it. IF you inherit a big ugly mess (which can happen in any NLE) FCPX can allow to absolutely plow through general groupings in a flash and you don't have to try and decipher what form of sanscrit the previous editor studied in college. Simply single click on the Event and you can see every single piece of media and get to work.


Return to posts index

Steve Connor
Re: FCP X as a database
on Nov 6, 2012 at 8:00:13 am

[Aindreas Gallagher] "Given the lack of in anger usage, I'm not qualified to speak to this"

Well said!

Steve Connor
'It's just my opinion, with an occasional fact thrown in for good measure"


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 5, 2012 at 4:07:43 am

[David Lawrence] "I think there's a potential bloat problem with the event and project library databases in situations like Oliver describes. What's the largest number of projects you've had in a library? How was the load performance? I'm curious because I even though I only have a handful of simple test projects, my project library load time is not great."

I don't know, maybe 20? I don't really worry about because of San Locations.

I hate to always bring this up, but San Locations solves this problem in spades. I am extremely lucky to work with a SAN. I realize that not everyone has that opportunity., but I feel it's worth it to keep bringing it up.

It allows the mounting and dismounting of Events/Projects from within the application. It is easy, it is fast, it is convenient, but most of all it gives FCPX better capabilities.

Why Apple doesn't add this capability into Non-SANd environments is beyond me. I mean, I know there's some technical reasons in that the SAN Location permissions are controlled by FCPX, but it seems a more "dumbed down" version could be included so people could mount/dismount local folders from within FCPX.

[David Lawrence] "I'm curious because I even though I only have a handful of simple test projects, my project library load time is not great."

Opening 20 FCP7 projects or 20 CS6 projects (trick statement) at once would cause some slow down too. X takes a different approach in that it presents all of the data visibly to you, but only actually 'loads' the data when you click on it. I seem to find once a Project/Event is loaded (cached?), it responds as normal.

I have an FCP7 project I have been working on for a client for going on two years now. It takes 15 minutes to open and about 48 seconds to save, and that's just one project. It's not extremely huge (about 65 MBs) but it has a ton of stuff in it. Big Pr CS6 projects take a long time to open as well. It's the nature of the NLE beast it seems.



[David Lawrence] "Can you get tags and keyword collections out of it?"

KW collections, sure.


Return to posts index

David Lawrence
Re: FCP X as a database
on Nov 5, 2012 at 6:42:43 am

[Jeremy Garchow] " have an FCP7 project I have been working on for a client for going on two years now. It takes 15 minutes to open and about 48 seconds to save, and that's just one project. It's not extremely huge (about 65 MBs) but it has a ton of stuff in it. Big Pr CS6 projects take a long time to open as well. It's the nature of the NLE beast it seems."

Yes, no argument from me there. It can take a long time in any NLE for any number of reasons.

[Jeremy Garchow] "[David Lawrence] "Can you get tags and keyword collections out of it?"

KW collections, sure."


I may have been unclear. Can you export the tag/keyword metadata in a way that is useful in other programs? For example, can keyword collection data be exported and translated into bins via XML and/or some kind of translation utility? If that were possible, I would consider using FCPX as preflight organization tool ala Adobe Prelude, and cut on a timeline that is more to my liking.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 5, 2012 at 12:49:59 pm

[David Lawrence] "I may have been unclear. Can you export the tag/keyword metadata in a way that is useful in other programs? For example, can keyword collection data be exported and translated into bins via XML and/or some kind of translation utility? If that were possible, I would consider using FCPX as preflight organization tool ala Adobe Prelude, and cut on a timeline that is more to my liking."

Keyword data is exported in Event/Project XMLs. It would be up to the receiving application/translator to make use of it.

Jeremy


Return to posts index

Andrew Richards
Re: FCP X as a database
on Nov 5, 2012 at 1:07:10 pm

[Oliver Peters] "How is FCP X any more of a database than Media Composer or Premiere Pro with embedded XMP data? "

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.

Best,
Andy


Return to posts index

Walter Soyka
Re: FCP X as a database
on Nov 5, 2012 at 1:51:06 pm

[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


Return to posts index

alban egger
Re: FCP X as a database
on Nov 5, 2012 at 5:12:33 pm

[Walter Soyka] "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."

That is absolutely true.

But once you are used to sort your media with metadata, there is no way back.
To create a bin of clips with specific format or resolution created on a certain date with a mix of keywords and maybe marked as favorites in an instance out of thousands of clips and dozens reels and cameras is only possible with a database working in the background.

It might seem to be Gmailish- "search - not sort", but it is a reality in many productions nowadays. Footage gets piled on an editors desk and the deadlines don´t always allow for logging in all possible ways that might not be even known on the first edit or to the first editor or director.



Return to posts index

Walter Soyka
Re: FCP X as a database
on Nov 6, 2012 at 1:19:41 am

[alban egger] "To create a bin of clips with specific format or resolution created on a certain date with a mix of keywords and maybe marked as favorites in an instance out of thousands of clips and dozens reels and cameras is only possible with a database working in the background."

I think pretty much all bin-side (for lack of a better term) NLE functions are only possible with a database working in the background.


[alban egger] "But once you are used to sort your media with metadata, there is no way back... It might seem to be Gmailish- "search - not sort", but it is a reality in many productions nowadays."

I didn't mean it as a criticism. I think "search don't sort" is a great idea.

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


Return to posts index

Franz Bieberkopf
Re: FCP X as a database
on Nov 5, 2012 at 5:27:54 pm

[Walter Soyka] "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."

Walter,

The "database" threads on here tend to be a lot of proselytizing - usually about power and imagined features - and little actual information.

A comparison of actual database structures (between Avid, 7, X, and Premiere) might be a place to start. I'm not sure we have either the information or expertise here to do such a thing - though I would love to be proved wrong.

Franz.


Return to posts index

Carsten Orlt
Re: FCP X as a database
on Nov 5, 2012 at 9:53:35 pm

[Franz Bieberkopf] "The "database" threads on here tend to be a lot of proselytizing - usually about power and imagined features - and little actual information."

Here is 'a little information' from Alban's post before:
But once you are used to sort your media with metadata, there is no way back.
To create a bin of clips with specific format or resolution created on a certain date with a mix of keywords and maybe marked as favorites in an instance out of thousands of clips and dozens reels and cameras is only possible with a database working in the background.


Yes it is true the world was spinning before FCPx and you could tag and find your footage before and will long after FCPx has gone. I personally don't care if FCPx is a database or if Avid is a spreadsheet or vice versa. I'm interested in usability and ease of operation. I have used Avid, Premiere and FCP 7 before and I must say, though confused in the beginning, the X way is the best for me. And if opening 100 Events will slow down this particular software, than I will adjust my organisation to avoid this problem. I could of course always say 'see not ready yet', but honestly the time I save these days organising my footage far out ways the time it takes to load the current Event with 3000 clips I'm working on.

FCPx is fully working now. They will improve it I'm sure, but I do not need to wait until 'they sorted things out', 'make it usable' and so forth.
If I for one second imagine
I would have to go back to describing footage by written description to be able to find content within one clip (rather than just skimming over it),

make sub clips which are not trim-able beyond their boundaries in the project timeline (every keyword or favourite section cut into the project timeline extends to the full length of the underlying media at all times),

use sub clips to mark favourite sections which I have to multiply into several bins because a sub clip section contains several talents (and than need to describe every single one separately to make sense of it later) only to find that I set the out point for the sub clip to early and than have to do it all again,

go through the timeline manually to identify all clips shot at a different frame rate (compared to just clicking on the fps keyword I created),

and I could go on and on..
..I would jump of the bridge :-))

Happy editing


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 5, 2012 at 10:13:17 pm

[Carsten Orlt] "If I for one second imagine

I would have to go back to describing footage by written description to be able to find content within one clip (rather than just skimming over it),

make sub clips which are not trim-able beyond their boundaries in the project timeline (every keyword or favourite section cut into the project timeline extends to the full length of the underlying media at all times),

use sub clips to mark favourite sections which I have to multiply into several bins because a sub clip section contains several talents (and than need to describe every single one separately to make sense of it later) only to find that I set the out point for the sub clip to early and than have to do it all again,

go through the timeline manually to identify all clips shot at a different frame rate (compared to just clicking on the fps keyword I created),

and I could go on and on..
..I would jump of the bridge :-))
"


Nominated for post of the day. lol

-------------------------------------------------------------


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


Return to posts index

Andrew Richards
Re: FCP X as a database
on Nov 5, 2012 at 6:29:40 pm

[Walter Soyka] "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."

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.

Best,
Andy


Return to posts index

Walter Soyka
Re: FCP X as a database
on Nov 6, 2012 at 12:15:02 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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 6, 2012 at 1:59:34 am

[Walter Soyka] "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?"

Another FWIW post, Not sure this is an answer, but just some more info from someone who knows the guts of X pretty well...

The database is CoreData - underneath is probably SQlite but it's not an SQlite database per sé. FCP X is built mostly on Core foundations in the Operating System, not directly rolled stuff. (Which is, of course, the right way to build on OS X).

-------------------------------------------------------------


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


Return to posts index

Andrew Richards
Re: FCP X as a database
on Nov 6, 2012 at 5:03:22 pm

[Walter Soyka] "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?"

SQLite would not scale well in terms of multiple user access, but then it isn't meant to serve more than a single-user local data store. Core Data has an obscure function called NSIncrementalStore that permits the use of data stores beyond the persistent stores native to Core Data (XML, Atomic, SQLite).

As soon as I noticed FCPX using CoreData and SQLite for Project and Event databases, I immediately began wishing for a successor to Final Cut Server that would essentially be live shared Events that FCPX would hook into as a native client. The hooks are there in Core Data, and one of the senior product managers for FCPX/Motion/Compressor came to Apple with the Proximity acquisition that begat Final Cut Server in the first place.

So what I'm wishing for isn't completely improbable. Highly improbable maybe, but not completely improbable. But to your main point, yes, most of the bluster about databases is misguided, and even my brand of it amounts only to fringe speculation about functionality only a tiny niche would be interested in. There is no inherent superiority in FCPX due to is use of Core Data, and indeed I think it contributes to a lot of the sluggishness observed when a project gets complex and necessarily performs a lot more I/O on its SQLite database for each new timeline input.

Best,
Andy


Return to posts index

David Lawrence
Re: FCP X as a database
on Nov 6, 2012 at 5:13:53 pm

[Andrew Richards] "There is no inherent superiority in FCPX due to is use of Core Data, and indeed I think it contributes to a lot of the sluggishness observed when a project gets complex and necessarily performs a lot more I/O on its SQLite database for each new timeline input."

Agreed. This is what I meant when I referred to bloat earlier.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 6, 2012 at 1:50:24 am

[Oliver Peters] "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."

Well, FWIW, I got this from someone who's quite familiar with the guts of FCP X...

It's more of a database than Premiere Pro because XMP metadata is only in the files and read into the App. PPro is a project based (binary file) application. Media Composer is fully database driven.
Each Event in FCP X is a database as is every Project. You can select multiple Events and search across all as if they were one database (try that in PPro or Media Composer)
None of the three apps has any database functions outside the limits of the project (or Events)


Again... FWIW..

-------------------------------------------------------------


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


Return to posts index

Oliver Peters
Re: FCP X as a database
on Nov 6, 2012 at 2:42:48 am

No offense, but you are being fed a bit of a spin answer ;-)

[Charlie Austin] "You can select multiple Events and search across all as if they were one database (try that in PPro or Media Composer)"

Since a Media Composer bin is pretty much like an FCP X Event, you can, in fact, search across bins using the Find function. PPro though is a single project file like FCP 7. However, PPro does use a filtering functions for search/finds.

[Charlie Austin] "Media Composer is fully database driven.....
....None of the three apps has any database functions outside the limits of the project (or Events)"


Seems to reinforce exactly what I said in the beginning. ;-)

- Oliver

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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 6, 2012 at 2:45:52 am

[Oliver Peters] "No offense, but you are being fed a bit of a spin answer ;-)"

Possibly... :-) but it is an answer. lol

-------------------------------------------------------------


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


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 6, 2012 at 3:12:18 am

[Oliver Peters] "Since a Media Composer bin is pretty much like an FCP X Event, you can, in fact, search across bins using the Find function. PPro though is a single project file like FCP 7. However, PPro does use a filtering functions for search/finds."

Actually, that comment got me to thinking - which is hard ;-) - But... An avid project is the master "container" that holds all your bins, sequences etc. An FCP X project is the same thing really. If you consolidate an X Project, it recreates all the Events (bins) that it contains... Maybe we've been looking at the X hierarchy from the wrong direction? I mean, if you do all your cuts in CC's in an event associated with a Project, isn't it pretty much exactly the same as an Avid project?

The analogy doesn't hold for what i do, which requires multiple different projects be produced from the same Event but... if you're cutting a Feature or a single show, why not do all your rough assembly (reels, scenes etc) in CC's in the Event(s), then do a final assembly in your single Project. In that scenario, isn't an X project almost exactly like an Avid project? When you're done, consolidate your master project to a Disk Image for archiving. Done.... It would also make the event huge and unwieldy, just like in FCP 7 or MC! I dunno... my head hurts... ;-)

-------------------------------------------------------------


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


Return to posts index

Paul Dickin
Re: FCP X as a database
on Nov 6, 2012 at 1:06:57 pm

[Oliver Peters] "there is ZERO database functionality outside of the Events currently visible inside FCP X"

[Jeremy Garchow] "The event and project structure is real close to what you find in the Finder and its all in one place. "

[Aindreas Gallagher] "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."

Hi
For historical reasons I am stuck in FCP 5-7 with an extended (2005-2012) project cluster derived from an archive of 3000+ digibeta tapes. In FCP 7 media managing the hundreds of mini-projects using and reusing this footage is really problematic.

Identification (= correcting misidentification in the original digibeta tape logs) has created a huge metadata pool. Ditto fragmentation - putting original footage back into one metadata bin. Archiving each individual mini-project's media (with shortened handles) creates further fragmentation. The magnitude of all these data stores isn't manageable within FCP 7, nor easily in the Finder. CatDV helps, also the dozens of notebooks I keep.

How would I want to go forward with this? And how would Apple's reincarnation of FCP X help? What sort of data-management/database do I need?

One thing I don't need is each assembly of related shots which comprised one mini-project in FCP 7 to continue to exist as a 'project'. All I need is a 'movie file' in a container (at Finder level) that would allow me to break it open to see the individual component clips and read the clip's source metadata. Isn't that what FCP X's Combined Clips are?

In my utopian view the Finder (tablet stylee) is hidden - except to 'developers' ;-), and the OS has a movie container format viewer (son of QuickTime) that directly opens Compound Clip movies in read-only mode.
But for an editor like me these CC's are editable in an application (FCP X)...

So in FCP X I would need a 'Finder-view' to show appropriate files on hard drives etc, which would include CC-like clips. Isn't this what the Event library is?

BUT. When I'm writing I don't want my books defaced with my metadata scribbling and with pages torn out and pasted into a work-in-progress scrapbook - the books get ruined in the process...

What I need for writing is a (digital) COPY of the original books etc. So in FCP X the Event is my view of the source assets, but I don't want my scribbling and page tearing (PIOPs) to apply to Event assets directly, but to Clip Collections created for my specific edit project.

I've been writing in a program called Scrivener which allows every sentence that I write to be annotated on associated metadata pages - its a five+ window application, file browser, text entry page, summary outliner, Inspector with added metadata fields like origination date and URL etc. and a separate document viewer window. This workflow is really productive.

So I'm looking at FCP X's workflows in the same way: It seems right to me that any editing metadata (PIOPs) I want to add to the project has to be achieved by a deliberate action - creation of a Favorite or metadata range etc.

As the Event is a 'global' creation (like books on a shelf) the core assets need to be kept intact and unaltered. But the Event can be added to by metadata creations - Collections and CCs etc which are added to the (virtual) shelf of my library.

The Projects are a separate entity - my thesis created from my reading of my library. The timeline, which can be turned into a CC and put in the Event library for future use.

In my utopian view I hope the puck is headed towards a YouTube/Google-like future where video assets are compound clips that can be broken down to be recycled, and documents, like web pages, have inbuilt metadata linkages that lead to all relevant source assets - text, pix etc.

I don't know enough about database structures to know how all the metadata associations inherent in this utopia 'relate'. ;-)



Return to posts index

Jeremy Garchow
Re: FCP X as a database
on Nov 7, 2012 at 3:29:02 am

[Paul Dickin] "So I'm looking at FCP X's workflows in the same way: It seems right to me that any editing metadata (PIOPs) I want to add to the project has to be achieved by a deliberate action - creation of a Favorite or metadata range etc.
"


Paul-

Good show.

You have very eloquently and precisely summed up how FCPX used to work before 10.0.6, and I completely agree with you.

I don't like what PIOPs always assume about the footage and my decisions within it.


Return to posts index

Charlie Austin
Re: FCP X as a database
on Nov 7, 2012 at 3:34:51 am

[Jeremy Garchow] "I don't like what PIOPs always assume about the footage and my decisions within it."

I missed PIOP when I started using X, and they really annoy me now that they put them back. Oh well, I've just gotten used to hitting the X key after I mark a range for whatever reason. Then it works like it used to. Uh, except for the hitting X all the time... ;-)

-------------------------------------------------------------


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


Return to posts index

Jeremy Garchow
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 4:48:06 am

[Charlie Austin] "Oh well, I've just gotten used to hitting the X key after I mark a range for whatever reason. "

If you truly want to clear a PIOP after adding a clip to the timeline, it's i,o, q (or d or w or whatever), shift f, option-x.

Then, and only then, will the piop truly be cleared. Boring.

I do see the value of them. For people who go through and mark their footage once, it's great, for people who don't mark their footage once and use the FCPX dynamic sort capabilities of the ummm *cough* database, they truly get in the way.

At least before PIOPs, there was a method to get PIOP like capability in favorites, now there's simply no choice without workflow crippling keyboard jockeying.


Return to posts index

Walter Soyka
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 1:21:42 pm

[Jeremy Garchow] "I do see the value of them. For people who go through and mark their footage once, it's great, for people who don't mark their footage once and use the FCPX dynamic sort capabilities of the ummm *cough* database, they truly get in the way. At least before PIOPs, there was a method to get PIOP like capability in favorites, now there's simply no choice without workflow crippling keyboard jockeying."

I was pro-PIOP, but the 10.0.6 range behavior revision giveth and taketh away. I like that non-favorite ranges are now preserved, because I thought that valuable user data was too easily nuked before, but I don't like that they are operationally equivalent to favorite ranges. 10.0.6 has traded one problematic behavior for another.

Here's my revised proposal: make the last non-favorite range selection (IOPs) a second-class range upon deselection of the clip.

When you click away from a clip with a non-favorite range selection, that range should be remembered, but deactivated -- a ghost range, both in the UI and in function. FCPX should not nuke it completely, but it should not treat it with the same primacy as properly favorited ranges were in 10.0.5.

When you click back into a clip, you should be able to recall the last non-favorite range with a keystroke. I think this accomplishes both goals: it retains PIOPish user data, but it doesn't break what was right about range behavior before. It allows a user to retrieve information they put in at only the minor inconvenience of a keystroke when they need it (like using a bookmark instead of leaving the book open), whereas the current behavior costs users who are using FCPX as it was designed keystrokes left and right to avoid unintentionally adding data to the wrong ranges.

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


Return to posts index

Oliver Peters
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 2:10:00 pm

[Walter Soyka] "I was pro-PIOP, but the 10.0.6 range behavior revision giveth and taketh away."

It's a prime example of an editorial feature designed by a programmer and not an editor.

- Oliver

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


Return to posts index

Jeremy Garchow
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 2:46:08 pm

[Oliver Peters] "It's a prime example of an editorial feature designed by a programmer and not an editor."

BS. They gave the people exactly what they wanted. "People" clamored for PIOPs, and that's exactly what was delivered. Besides the multiple range capability, they work exactly like FCP7, is it not what people asked for? FCP8?

Anything you add on top of these are going to revert back to a state of Favorites.

If PIOPs want to become yet another selectable, sortable, and visually identifiable range, I am all for it, but you are going to have to hit a key to save them instead of hitting a key to clear them.

What I mean by this is that I can sort by a number of different ranges in the viewer, just not by PIOPs.

In list view, I cannot see PIOPs save for the one filmstrip at the top of the Browser.

In the countless threads that we talked about this, I always said that Favorites were a tool of intent, now perhaps we can see what was meant by that.

Just give me an off switch or a temporary off switch. If I want to range a whole clip instead of a PIOP, let me hit option-keyword or option-favorite, or better yet, let the PIOP folks hit the extra option key.

There is merit to having the ability to select multiple ranges on a clip. I love that functionality, but let me decide what needs to happen with those ranges instead of constantly holding on to decisions that I might not want.

Give me f (favorite) and u (unfavorite) back, just so we are clear on f.u.'s.

Jeremy


Return to posts index

David Lawrence
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 5:08:51 pm

[Oliver Peters] "It's a prime example of an editorial feature designed by a programmer and not an editor."

[Jeremy Garchow] "BS. They gave the people exactly what they wanted. "People" clamored for PIOPs, and that's exactly what was delivered. Besides the multiple range capability, they work exactly like FCP7, is it not what people asked for? FCP8?"

I finally had a chance to download and play with 10.0.6 so now I understand your frustration. You're right. Apple blew it with PIOPS.

But Oliver's exactly right too. The reason they blew it is because ProApps engineers 1) oversimplified the selection paradigm and 2) misunderstood what editors were asking for.

The problem stems from a core design mistake - mixing range selection with marking IN and Out points. These are two entirely different editorial intentions.

Ins and Outs are marks.

Range often has nothing to do with why editors mark in and/or out. That's why in FCP7, you have a Range Selection Tool (GGG).

In FCPX, marking in and out has been folded into the Range Selection Tool. This oversimplification is why adding persistence breaks the selection model.

What I think editors have been asking for and what should have been added, are a new class of In/Out markers.

The rules should be simple and obvious -- only one In and/or Out per clip. If set, they persist and take priority, and other than that, if you don't want to use them, don't set them and everything works as before -- the range In/Outs take over.

Range selection is not the same as marking In/Out.

Oliver's right. The PIOPs mess is a crystal clear example of what happens when programmers design UI without understanding what the end user really wants.

Also, no PIOPs on the timeline = FAIL.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 10:43:13 pm

[David Lawrence] "The reason they blew it is because ProApps engineers 1) oversimplified the selection paradigm and 2) misunderstood what editors were asking for."

Wow. A bit revisionist but I'll allow it.

So now that the functionality is there, you don't like it? What did you expect them to do? This is exactly why I didn't want PIOPs as they make no sense in this application. It is not FCP8 or Pr 6.1, it is FCPX

You can't compare FCP7 ranges to FCPX ranges, they aren't even in the same league and don't work in the browser at all.

[David Lawrence] "The rules should be simple and obvious -- only one In and/or Out per clip. If set, they persist and take priority, and other than that, if you don't want to use them, don't set them and everything works as before -- the range In/Outs take over."

Fixed in and out markers don't fit the X convention. Traditional in and out markers would get old fast when one starts to sort the timeline between all of the differing ranges and views.

What this proves to me is that people aren't using the FCPX browser as it was designed and intended. They do not understand the dynamic nature of it (dynamic meaning ever changing) and must be locked in to fixed bin and viewer like behaviors. Old habits truly die hard.

That's fine, there are plenty of other application that have those conventions. FCPX doesn't need to work that way.

Jeremy


Return to posts index

Paul Dickin
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 11:32:25 pm

[Jeremy Garchow] "...people aren't using the FCPX browser as it was designed and intended. They do not understand the dynamic nature of it (dynamic meaning ever changing) and must be locked in to fixed bin and viewer like behaviors. Old habits truly die hard."
Hi
"...very eloquently and precisely summed up..." :-)



Return to posts index

Oliver Peters
Re: FCP X as a database and a PIOP nightmare
on Nov 8, 2012 at 12:27:47 am

[Jeremy Garchow] "What this proves to me is that people aren't using the FCPX browser as it was designed and intended. They do not understand the dynamic nature of it (dynamic meaning ever changing) and must be locked in to fixed bin and viewer like behaviors. Old habits truly die hard."

Or maybe they simply don't like it and don't see it as better.

- Oliver

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


Return to posts index

Jeremy Garchow
Re: FCP X as a database and a PIOP nightmare
on Nov 8, 2012 at 1:30:38 am

[Oliver Peters] "Or maybe they simply don't like it and don't see it as better."

And that is half my point.

If there's no value in it for the editor, personally, why stick with it? There are other tremendously valuable NLEs on the market today that are getting better every day.

The organization of FCPX, I find, to be the crown jewel. If a person doesn't like the organizational structure, I can't imagine they will like the timeline? If they don't the organization and the timeline, WTF are they doing here?


Return to posts index

David Lawrence
Re: FCP X as a database and a PIOP nightmare
on Nov 8, 2012 at 1:21:04 am

[Jeremy Garchow] "Wow. A bit revisionist but I'll allow it."

I still firmly believe persistent In/Out marks are necessary. But yes, I have revised my thinking on how it needs to be implemented.

[Jeremy Garchow] "So now that the functionality is there, you don't like it? What did you expect them to do? This is exactly why I didn't want PIOPs as they make no sense in this application. It is not FCP8 or Pr 6.1, it is FCPX"

At first, I expected them to do something like what they've done. But it wasn't until I actually tried it that I understood why you were complaining. The problem isn't that PIOPs don't belong in the application, the problem is that the basic UI model for selection and marking is oversimplified and incomplete.

[Jeremy Garchow] "You can't compare FCP7 ranges to FCPX ranges, they aren't even in the same league and don't work in the browser at all."

Sure you can.

The extra features and functions in FCPX are great, but that doesn't change the fact that two entirely different editorial tasks have been shoehorned into range selection.

It seems pretty obvious but I'll say it again. Marking In and Out is not the same as selecting a range.

It's no surprise PIOPs are a mess. This is a classic example of programmers adding a feature without understanding the intention or need.

[Jeremy Garchow] "Fixed in and out markers don't fit the X convention. Traditional in and out markers would get old fast when one starts to sort the timeline between all of the differing ranges and views. "

They could be if they were properly designed. The UI for marking In and Out needs to be completely separate from the range selection UI. Don't like them? Fine, don't use them. Everything would continue working they way you like. Why not build a UI flexible enough to give everyone what they want? I say it's entirely possible.

[Jeremy Garchow] "What this proves to me is that people aren't using the FCPX browser as it was designed and intended. They do not understand the dynamic nature of it (dynamic meaning ever changing) and must be locked in to fixed bin and viewer like behaviors. Old habits truly die hard."

What this proves to me is that ProApps engineers need to do a better job understating basic NLE features and feature requests. Case in point - the new Event Viewer.

No time indicator and no skimming? Really? Why not put these directly in the Event Viewer window? Seriously weak.

I get FCPX is a new model. I really, truly do. It's not about old habits dying hard. For me, it's about whether the new FCPX UI model is flexible and scalable enough to accommodate the full universe of editorial needs and styles Legend once led.

I really hoped I would be more impressed with 10.0.6. There are some nice improvements, but the bottom line is the interface really is still annoying.

And it's a drag that they've broken your workflow with this bogus PIOP implementation. I truly hope they fix it. But the way to fix it is not with an on/off preference. They need to fix it by understanding why so many editors were clamoring for it to begin with. It's not old habits, it's editing 101.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: FCP X as a database and a PIOP nightmare
on Nov 8, 2012 at 1:57:55 am

[David Lawrence] "Sure you can."

Not really. The range selection tool is timeline only in FCP7. You simply cannot perform the same browser side functions in 7 as you can in X with ranges as they simply don't exist. You can't set the beginning/end of range with keyboard shortcuts in 7, and actions applied to ranges are applied to that one clip only.

It's a different ballgame.

[David Lawrence] "It seems pretty obvious but I'll say it again. Marking In and Out is not the same as selecting a range."

I know what you're saying and I understand the distinction you are trying to make.

FCPX does have fixed in out markers when opening a compound clip. They are determined by the boundary of the compound in the enclosing timeline.

This functionality would not work very well the Event Browser, especially when you start to sort clips by Favorite, Keyword, Filmstrip, etc. It will fall down very quickly and start to not make sense, but that seems pretty obvious, right?

I mean, Apple added exactly what was wanted, and you really think they didn't thought this through, or is it was designed "by a programmer and not an editor because programmers don't know us like we know us"? Get the heck on outta dodge. This is why I think they gave the people exactly what they wanted because FCPX works the way it works, and it simply works differently. It isn't any less capable that FCP7 with regards to PIOPs and the range system.

[David Lawrence] "They could be if they were properly designed. The UI for marking In and Out needs to be completely separate from the range selection UI. Don't like them? Fine, don't use them. Everything would continue working they way you like. Why not build a UI flexible enough to give everyone what they want? I say it's entirely possible."

I've asked for an off switch or modifier.

[David Lawrence] "What this proves to me is that ProApps engineers need to do a better job understating basic NLE features and feature requests. Case in point - the new Event Viewer.

No time indicator and no skimming? Really? Why not put these directly in the Event Viewer window? Seriously weak."


The time indicator and skimming are done on the filmstrip. TC availability does need help. There needs to be more tc window than one.

[David Lawrence] "I get FCPX is a new model. I really, truly do. It's not about old habits dying hard. For me, it's about whether the new FCPX UI model is flexible and scalable enough to accommodate the full universe of editorial needs and styles Legend once led.

I really hoped I would be more impressed with 10.0.6. There are some nice improvements, but the bottom line is the interface really is still annoying.

And it's a drag that they've broken your workflow with this bogus PIOP implementation. I truly hope they fix it. But the way to fix it is not with an on/off preference. They need to fix it by understanding why so many editors were clamoring for it to begin with. It's not old habits, it's editing 101."


It's annoying to you, but not to everyone. I believe that the way to move FCPX forward is not to turn off the magnetic timeline which has been asked over and over in this forum. As a matter of fact, the magnetic timeline does turn off if you know how to use it and it's been there since day 1, like favorites.

Oliver wants to break up 100 cameras in to 100 Events. I'd use one Event and metadata. (No offense, Oliver, just saying).

There is no editing 101 when it comes to interface, only metaphors to technical limitations that have existed for a very long time.

It's time to embrace Editing 102, or stick with 101, there's plenty of places that still teach it.

FCPX has the modern production metaphor of grouping down. In my edits, more and more and more, handling large groups of footage is the norm. It's no longer one camera, one shoot, but I guess programmers don't know us like we know us.

Jeremy


Return to posts index

David Lawrence
Re: FCP X as a database and a PIOP nightmare
on Nov 10, 2012 at 12:02:39 am

[Jeremy Garchow] "The range selection tool is timeline only in FCP7. You simply cannot perform the same browser side functions in 7 as you can in X with ranges as they simply don't exist. "

Yes.

[Jeremy Garchow] "You can't set the beginning/end of range with keyboard shortcuts in 7, and actions applied to ranges are applied to that one clip only."

Yes.

[Jeremy Garchow] "It's a different ballgame."

Yes, and...

that does not change the fact that a range selection is still a range selection.

[Jeremy Garchow] "FCPX does have fixed in out markers when opening a compound clip. They are determined by the boundary of the compound in the enclosing timeline.

This functionality would not work very well the Event Browser, especially when you start to sort clips by Favorite, Keyword, Filmstrip, etc. It will fall down very quickly and start to not make sense, but that seems pretty obvious, right?"


Right. But compound clips have nothing to do with an editor wanting to mark their next cut.

[Jeremy Garchow] "I mean, Apple added exactly what was wanted, and you really think they didn't thought this through, or is it was designed "by a programmer and not an engineer because engineers don't know us like we know us"?"

Yep, I think the evidence speaks for itself. Why else would your selection workflow would be messed up right now? Apple's recent history is filled with examples of poorly thought out software design choices. Breaking the "Save As" command Mac OSX Lion, for example.

[Jeremy Garchow] "I've asked for an off switch or modifier."

Sure, that would help. But ultimately it's a band-aid. I think a better approach would be for them to get the PIOP design right. It's very doable.

[Jeremy Garchow] "It's annoying to you, but not to everyone. I believe that the way to move FCPX forward is not to turn off the magnetic timeline which has been asked over and over in this forum. As a matter of fact, the magnetic timeline does turn off if you know how to use it and it's been there since day 1, like favorites."

[Jeremy Garchow] "There is no editing 101 when it comes to interface, only metaphors to technical limitations that have existed for a very long time."

Yes, but maybe there's another reason some interface metaphors have stood the test of time. Maybe it's because they're appropriate and they work well. Technology is just one aspect of Human Interface Design.

Don't get me wrong. I love innovation and appreciate Apple's drive to push it. There are many great new ideas in FCPX and it continues to get better with every release. But I think we agree there's also a lot of room for improvement.

I believe the best way to move FCPX forward is to maintain a healthy critical eye and dialogue. It's good for FCPX, for Apple, and ultimately us as editors. Otherwise, we're more likely to see future design nightmares as programmers add new features. Another reason why this forum continues to be interesting and relevant.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: FCP X as a database and a PIOP nightmare
on Nov 10, 2012 at 1:44:38 am

[David Lawrence] "Right. But compound clips have nothing to do with an editor wanting to mark their next cut."

No no brother. That's not what I am saying. I am saying the ins and outs of compound clips are a fixed version of traditional in and out points, that ignore ranges.

Like this:



in_out.png

So now when we start adding ranges to this PIOP idea, and we start sorting clips by range views, flimstrip views, etc, the ins and outs won't make any sense. If you are saying you want to attach an in point and an out point to a clip, like a marker, then I guess I see how that could happen, I just don't know what it will accomplish that ranges don't. You can add an in point and out, and sort the clips by another set of data and then the in and out will get all jumbled up.

Let's say you mark an in and out on a clip that's 5 minutes long, and you have 10 favorite ranges within that 5 minute in and out range.

You sort the (*edit) Event by favorites which makes 10 "clips" from that one clip. Now your in and out is spread out across two clips that are now discontinuous. What does FCPX do? What if you then want to sort back to all clips, does fcpx add back the original 5 min in and out? What if you take 5 of those 10 clips, mark their own in and out and want to add those to the end of the timeline? Then you sort back to all clips? Which in and out is kept?

This is the same argument rehashed from earlier discussions on PIOPs.

They should have just left alone and gave people more time to adapt.

The Event browser, when you start using it for all of it's dynamic capabilities, doesn't fit a traditional in/out structure, at least in my opinion. The favorite system, works very well, even if you have to add a key to your in/out marking process.

[David Lawrence] "Yes, but maybe there's another reason some interface metaphors have stood the test of time. Maybe it's because they're appropriate and they work well. Technology is just one aspect of Human Interface Design.

Don't get me wrong. I love innovation and appreciate Apple's drive to push it. There are many great new ideas in FCPX and it continues to get better with every release. But I think we agree there's also a lot of room for improvement.

I believe the best way to move FCPX forward is to maintain a healthy critical eye and dialogue. It's good for FCPX, for Apple, and ultimately us as editors. Otherwise, we're more likely to see future design nightmares as programmers add new features. Another reason why this forum continues to be interesting and relevant."


And I think we have seen that PIOPs aren't working well here. It's time to change it up, which was happening, until Apple did us a solid by adding an old "feature" metaphor back due to user demand.

The people wanted PIOPs, they delivered. I know, I keep saying that.

I just wish Apple would carry out the ultimate vision, get in all the features they want without compromise. There's evidence of what is possible, this latest released showed us a lot. It's still not perfect, I've always known and said there's room for improvement, but that is true of all software, even the most "mature".

Jeremy


Return to posts index

Walter Soyka
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 6:09:36 pm

[Jeremy Garchow] "Just give me an off switch or a temporary off switch. If I want to range a whole clip instead of a PIOP, let me hit option-keyword or option-favorite, or better yet, let the PIOP folks hit the extra option key... Give me f (favorite) and u (unfavorite) back, just so we are clear on f.u.'s."

We need NLE cheat codes, like typing FUPIOPS in the Event Browser to revert to 10.0.5's range functionality.


[Jeremy Garchow] "In the countless threads that we talked about this, I always said that Favorites were a tool of intent, now perhaps we can see what was meant by that."

I get that Favorites were a tool of intent. But so were IOPs, once upon a time. Why, in an application that doesn't even let you save your project, should you have to manually save your IOPs? Previous versions of FCPX made range selection too fragile, and the current version has over-corrected.

This is why I've retreated from my original PIOPs stance. When we first discussed this at length some months ago, I backed off of wanting PIOPs and instead suggested that selection activity should be pushed onto the undo stack, so at least you could get your selection back after clicking errantly off of it.

Now I'm proposing that PIOPs become SIOPs -- stored in and out points. They shouldn't be so easily misused (the mess of 10.0.6), but they shouldn't be so easily forgotten either (the mess of 10.0.5 and previous).

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


Return to posts index

Jeremy Garchow
Re: FCP X as a database and a PIOP nightmare
on Nov 8, 2012 at 2:41:50 am

[Walter Soyka] "We need NLE cheat codes, like typing FUPIOPS in the Event Browser to revert to 10.0.5's range functionality."

Now that, sir, is the best idea I've heard all day. It would allow to swear at the software and it would react.

Let's all send Apple feedback on this all important feature.


Return to posts index

Walter Soyka
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 6:18:49 pm

[Oliver Peters] "It's a prime example of an editorial feature designed by a programmer and not an editor."

I'm not opposed to editorial features designed by programmers -- that's at least in part how we got the good stuff in FCPX, right?

But editors do need to vet the design. This PIOP implementation should have been shot down in the beta program.

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


Return to posts index

Oliver Peters
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 6:22:32 pm

[Walter Soyka] "This PIOP implementation should have been shot down in the beta program."

Apple - beta program? I thought that was the paying customer ;-)

- Oliver

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


Return to posts index

Walter Soyka
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 6:25:43 pm

[Oliver Peters] "Apple - beta program? I thought that was the paying customer ;-)"

I see you see what I did there :)

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


Return to posts index

Charlie Austin
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 6:58:59 pm

[Walter Soyka] "This PIOP implementation should have been shot down in the beta program."

I guess I don't understand what the fuss is all about. I mean, I was annoyed by the behavior up through version .05, but I got used to it. And I'm not crazy about having PIOP's back, because I got used to not having them , but it doesn't seem to be that big a deal. Take favoriting ranges in a clip.. pre .06 I'd set an I/O, hit F, maybe rename it or not, continue playing, do it again etc. Still works the same in .06.

Pre .06 if I set an I/O point for whatever reason, and then clicked on the clip, the I/O went away and the entire clip was set as a range. Now I need to hit the X key to have it do that, which is fine because maybe I didn't want the I/O to go away, which is the whole point of PIOP's right?

So unless I use a modifier key to set multiple saved I/O points, and I can think of a couple reasons why i might want to do that but mostly I wouldn't... What's the difference? the only thing I see is that now I need to hit a key (X) to have it behave like it did when I clicked on the clip in earlier versions... What am I missing here?

edit: Is the issue the fact that when you highlight a clip in the library it shows all your Favorited ranges selected? Again, the X key clears it, but I'm gonna send feedback to Apple requesting they turn that off and maybe add a "select all ranges" command or something. But again, it's just a keystroke to make it go away...

-------------------------------------------------------------


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


Return to posts index

Walter Soyka
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 7:16:47 pm

[Charlie Austin] "I guess I don't understand what the fuss is all about. I mean, I was annoyed by the behavior up through version .05, but I got used to it. And I'm not crazy about having PIOP's back, because I got used to not having them , but it doesn't seem to be that big a deal. Take favoriting ranges in a clip.. pre .06 I'd set an I/O, hit F, maybe rename it or not, continue playing, do it again etc. Still works the same in .06. "

Jeremy put it very well a couple weeks ago [link]:

Jeremy Garchow "You have no idea what range(s) are in any of the clips, so if you start keywording a bunch of things at once or tagging them, you are only tagging the ranges, and not the clips. It was so much easier with just favorites as the favorite ranges didn't override a clip range unless you selected those ranges. I'd like an option to turn this off."

I was a PIOP cheerleader (still am), but this implementation is bogus. Like David said, ranges are now overloaded. Ranges and PIOPs have some overlap, but not this much.

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


Return to posts index

Charlie Austin
Re: FCP X as a database and a PIOP nightmare
on Nov 7, 2012 at 7:29:57 pm

[Walter Soyka] "I was a PIOP cheerleader (still am), but this implementation is bogus. Like David said, ranges are now overloaded. Ranges and PIOPs have some overlap, but not this much."

OK, that makes sense. I vote for the "turn it off" button too. ;-) Although, In list view, you can see what ranges are set in the clip, though maybe not in filmstrip view. Until it changes, the X key, which sets the entire clip as the range, is your friend I guess...

-------------------------------------------------------------


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


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]