FCP X as a database

[Charlie Austin]

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

[Jeremy Garchow]

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

[Jeremy Garchow]

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

[Charlie Austin]

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

[Jeremy Garchow]

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

[Walter Soyka]

[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

[Oliver Peters]

[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

[Jeremy Garchow]

[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

[David Lawrence]

[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

[Walter Soyka]

[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