Forum Replies Created

Page 87 of 97
  • Chris Kenny

    June 21, 2011 at 10:30 pm in reply to: Why is it So Dumbed Down?

    [Greg Burke] “Just Went Next store to out Creative Neighbors. They Have a copy there fooling around with, Why is everything Dumbed down so much? does apple think Numbers and quick keys are intimidating? Stuff is literally buried under tons of thing, and so much Order has you depending on Viusal Picture rather that Naming and Logging? Why would they change this much? Now I understand its 1.0 and I curous to see what they do with the future of FCP X. But why would apple tease and put all new features we would love to have in FCP 7 with out a Horrid interface.”

    The interface is deeper than it looks at first glance, and there’s tons of keyword/metadata support there. Some things work very differently; as an FCP 7 editor, it looks like lots of things are missing, but the same ends are generally achievable, often in more convenient ways, with the new toolset.

    The only place where it really falls down right now is workflow, with the lack of video I/O and XML/EDL/OMF export. In terms of actual editing, it seems pretty well thought out.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read our blog.

  • Chris Kenny

    June 21, 2011 at 10:25 pm in reply to: A ‘pro’ app with missing features

    [Andrew Corneles] “Now looking into the export features and seeing youtube, iCNNwhatever,
    It’s obvious to me where the resources were spent.”

    That’s kind of a silly argument. All those web export formats are fairly trivial user interface code wrapping H.264 file exporting. That’s not “where the resources were spent” because it would have barely required any resources.

    My guess is that by far the most time consuming element of this release was the underlying playback/rendering technology, which is, of course, all going to carry over into future releases that add more workflow features.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read our blog.

  • [Aindreas Gallagher] “but chris, for god’s sake I can’t even ‘save as’ anymore. The moronic software is relentlessly autosaving on top of itself like a maniac. I need to be able to fork and park the file saving at points.”

    I suspect that problem goes away with Lion’s ‘Versions’ feature.

    [Aindreas Gallagher] “And multiple timelines are not a cludge. They’re an important part of iterating different conceptions of the edit.”

    But FCP X provides tools explicitly for the purpose of doing this sort of thing in a single timeline. For instance, you can group all the shots in a scene into a compound clip (basically a less screwy nested sequence), and then duplicate it as an audition, which lets you easily swap different versions of it into and out of your main sequence.

    Basically, FCP X does support multiple sequences in a project, but it drops support for multiple top-level sequences in favor of support for better hierarchical organization of sequences.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read our blog.

  • [Aindreas Gallagher] “You can’t tell it where you want to save a project (always saves in your “movies” folder like imovie.”

    This is not true. From the Project Library you can right-click any volume and choose ‘New Project’.

    [Aindreas Gallagher] “Where you had a collection of sequences and bins that were relevant to the specific project. Instead each project has one (1) timeline only, or in other words each timeline is it’s own project.”

    This is true, but sort of misleading, because with the addition of ‘events’, the role of projects is very different in FCP X than in FCP 7. Also, many things that involved horrible kludges with multiple timelines in FCP 7 can be done better in FCP X in a simple timeline with some of the new timeline features.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read our blog.

  • Chris Kenny

    June 21, 2011 at 4:16 pm in reply to: OMF and AAF Export via Automatic Duck

    The fact that a third-party tool can offer this feature implies there’s some way to get timeline data out of FCP X. It doesn’t have an explicit XML export, but has anyone checked what its native file format is? It wouldn’t be too surprising if it were XML-based; that’s common for many of Apple’s apps these days.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read Does FCP X make project files obsolete? on our blog.

  • Chris Kenny

    June 16, 2011 at 6:53 pm in reply to: Larry Jordan speaks about FCPX

    [Simon Ubsdell] “The big news story (from the start of part 3) is the one headlined by those great guys at fcp.co, to quote:

    FCPX 1.0 “It will not be ready for professional use” says Larry Jordan

    Now that’s what I call a “jawdropper”!”

    There’s a huge difference between “Hey, it’s probably not a great idea to move critical production workflows to brand new 1.0 software” (what Jordan appears to be saying) and “Apple is deliberately abandoning professional users because they’re more interested in shiny toys” (the line the trolls are pushing).

    The former isn’t a “jawdropper”. It’s common sense. Had Jordan clearly said the latter that would have indeed been significant, but that’s not the impression I got.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read Does FCP X make project files obsolete? on our blog.

  • Chris Kenny

    June 11, 2011 at 6:55 pm in reply to: Uninformed Speculation about Mac Pros

    You’d still need to keep a couple of internal slots for GPUs — Thunderbolt is only 4X PCIe.

    But yeah, video I/O cards, RAID controllers, and practically everything else can easily be moved out of the box with Thunderbolt.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read Does FCP X make project files obsolete? on our blog.

  • Chris Kenny

    May 10, 2011 at 2:30 pm in reply to: remember the old days!

    [Dennis Radeke] “I didn’t mean to be vague. More RAM = better performance in most cases, whether directly or indirectly. In a 32-bit app world people were used to having 8 cores and 4gb of addressable memory (like FCP 7). With 64-bit applications and computing, you want to have plenty of memory so that your CPU’s can work at peak efficiency. Here’s a nice article from Adobe’s Todd Kopriva about starving your CPU’s in AE: https://blogs.adobe.com/toddkopriva/2009/12/performance-tip-dont-starve-yo.h...”

    I’m aware of the general principle, I’m just very skeptical about whether being able to use, say, 4 vs. 8 GB of RAM really makes much difference for multithreaded rendering of things like color correction filters, lower thirds, etc. — the nuts and bolts things that editors want to be faster.

    [Dennis Radeke] “Twice as fast, no.”

    Well, this is my point. Even “twice as fast” is a pretty small speedup compared with the typical performance increase associated with moving a suitable task to the GPU, and the performance benefits associated with 64-bit addressing and process don’t even provide that. I’m not saying you guys shouldn’t have been bragging about being 64-bit before Apple, but it’s misleading to sort of imply you get 2/3 of the Mercury Playback Engine without an NVIDIA GPU, when you don’t get anything close to 2/3 of the performance enhancement.

    [Dennis Radeke] “I could go on but lets agree that you’re not going to buy in to what I’m saying. It’s obvious that you’ve not tried a native 64-bit editing application and until you do (FCP X), you won’t see the benefits.”

    I expect most of the performance benefit of FCP X also won’t be directly related to the fact that it’s 64-bit.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read Does FCP X make project files obsolete? on our blog.

  • Chris Kenny

    May 9, 2011 at 2:54 pm in reply to: remember the old days!

    [Dennis Radeke] “I’m curious if there are any other reasons or thoughts about why FCP X might be faster.”

    Err… that article is frankly a little questionable. It breaks down the Mercury Playback Engine into three components — 64-bit memory addressing, 64-bit processing, and GPU acceleration, and then insists that you still get two of the three even without an NVIDIA GPU.

    This is fairly screwy.

    64-bit addressing offers no performance benefit unless performance was previously limited by RAM available to the app. Now, there are some algorithms where the ability to use more RAM during processing can speed things up… but this mostly doesn’t apply to video. The post seems to be kind of vaguely implying they need the extra RAM to enable multithreaded processing, but frankly that’s a little questionable. Most processing of video can work with frames one at a time, and individual video frames aren’t all that big. There might be some significant benefit here with a few filters, but I doubt the overall difference is very large. Think about it like this: do you really think throwing 8 GB of RAM at Premiere Pro makes it even twice as fast as it is with 4 GB? While there are rare exceptions (e.g. databases where more RAM means you never have to hit the disk), most software tends not to work like that.

    Meanwhile, 64-bit processing can result in significant speedups… if you’re processing lots of 64-bit integer data. Which is not common, and not really applicable to video processing. The highest quality at which video is commonly processed is 32-bits/channel, and that’s usually 32-bit floating point data, not integer data at all.

    x86-64 does have an odd quirk relevant to this, however. x86 has always been register-starved, and AMD (everyone forgets AMD came up with x86-64 while Intel was off fooling around with Itanium) took the opportunity to add more registers with the new spec. This provides certain general performance benefits, but they’re not huge. We’re talking in the range of 10-20% here for the most part — not the difference between “spend all day staring at progress bars” and “you do’t have to render anymore”.

    And then there’s the GPU, which for tasks suitable for GPU processing can result in processing dozens or even hundreds of times faster. That really can be the difference between “spend all day staring at progress bars” and “you do’t have to render anymore”.

    So while you might be getting 2/3 of the “bullet points” of the Mercury Playback Engine without GPU acceleration, you’re probably getting less than 1/10 of the performance enhancement.

    Meanwhile, FCP X will offer GPU acceleration on every Mac with discreet graphics, e.g. the Mac Pro plus the iMac, and the 15 and 17″ MacBook Pro models. And next year with Ivy Bridge, OpenCL should even be supported on Intel’s integrated GPUs, which means every Mac Apple sells will be able to benefit from GPU acceleration in FCP X before too long.

    Now, maybe Adobe is at work furiously creating a parallel implementation of Mercury for OpenCL. But, well, we’ll see.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read Does FCP X make project files obsolete? on our blog.

  • Chris Kenny

    May 8, 2011 at 2:31 pm in reply to: remember the old days!

    [Craig Seeman] “I do think some post houses are going to look at FCPX and iMac Thunderbolt as an affordable way to add seats even it may be limited to the kinds of jobs it can handle at first.”

    Probably not even all that limited. You’ll be able to do anything up to 2K 4:4:4 over Thunderbolt, in terms of both video I/O and storage bandwidth. The 27″ 3.1 GHz iMac is only ~15% slower in terms of CPU than a 3.33 GHz 6-core Mac Pro from last year. And, of course, FCP X, with GCD and OpenCL, is going to run a lot faster than FCP 7 ever did.

    A 2011 iMac running FCP X will almost certainly be a significantly better all-around editing system than a 2010 Mac Pro running FCP 7.

    Video editing is quickly moving down the “used to require expensive high end hardware, but not really all that challenging for modern systems” path that so many other types of software have followed over the years.


    Digital Workflow/Colorist, Nice Dissolve.

    You should follow me on Twitter here. Or read Does FCP X make project files obsolete? on our blog.

Page 87 of 97

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