APPLE FINAL CUT PRO: Apple Final Cut Pro X FCPX Debates FCP Legacy FCP Tutorials

Re: FCP X as a database and a PIOP nightmare

COW Forums : Creative Community Conversations (was FCPX Debates)

Respond to this post   •   Return to posts index   •   Read entire thread

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

Posts IndexRead Thread 

Current Message Thread:

© 2020 All Rights Reserved