'new mac pro's & fcpx

In my case, I'm convinced it's because I do a ton of gameplay footage as B-roll. I always optimize the media during import, but as the video goes on and more and more gameplay footage gets added with in camera footage, FCPX starts to choke. Maybe the optimize media option isn't 100% converting video game capture footage to Apple Pro Res 100%?! I'm guessing... But if I do a video with only in camera footage, I can edit fine all day long.

I've confirmed this with another big YouTube gaming channel who also edits with FCPX. He sticks with FCP 7 and the performance is fine...and only uses X for green screen and multicam stuff.

Edit: Question - if there any benefit to using Compressor on the gameplay footage first? I haven't used Compressor much, so I don't know where even to begin.

Good point, but if you are converting to 422, it should be only 422 on the timeline and you shouldn't see delays.

I can understand mixing of footage could slow things down, but all my footage is usually transcoded into 422 before edits.. sometimes on small projects I dont bother with doing that. Now, that being said, if FCPX can work with various footage, that various footage no matter the codec should work fine as well on the timeline, because FCP 'supports' it.
An argument can be made either way for that position, understandably..

I really dont know if converting footage to 422 first in compressor, then importing it into FCPX (so FCPX never even sees the original media) would make any difference.. a good thing to test out however..

@dkag7

What you are describing is pretty much what I am seeing also. It's not necessarily happening at the start of a new project but eventually some or all of those things will be happening. Restarting does not always help either.

I noticed a difference in timeline performance when I updated my laptop from 10.0.9 to 10.1.4. The interface definitely "slowed down".

I have been through all of the troubleshooting and maintenance that others have mentioned and it didn't make a difference. I think it's curious that others not seeing this. If the next update does not fix the issue I am going to completely strip everything out of my system and start over from scratch again. If that doesn't fix it I will be talking to Apple.

Regardless of the issue though, I can still get things done faster and (IMHO) better in FCP X than other systems I've worked on. If they can fix this I'll be very happy.

you may have better luck, but I did it twice on two different systems (both mac pro's 3,1 & 5,1)

Doing this rules out any 3rd party stuff, and other OS apps (that may or may not be running while FCPX is open)

So now I am left with, 'is a Mac pro 5,1 with gtx 680 (tried both Nvidia and apple drivers) Raid SSD, 32gigs RAM & a 3.33 Ghz CPU not compatible with FCPX?" By compatible I mean a fluid working application and an app where I am not using 25% of my time dealing with application issues.

The FCPX software really needs to make improvements as the timeline grows beyond a few clips. I have a cylinder Mac Pro trash can and FCPX is better than it was on my old 2006 Mac Pro 1,1 but not by as much as it should be. And by that I mean it is marginally better. Like Metal Jesus says (HI!) I use FCP7 most of the time except for the live action footage stuff and FCP7 is always 100% instantaneously responsive. It always has been. FCPX NEEDS to be equally responsive in the timeline at all times. FCPX must currently have very poor or unoptimized code or something. They need to fix it pronto. It's embarrassing for us Mac users, really. Especially those of us who have spent a crap-ton on hardware. It's a real problem that exists and nobody can deny it.

Don't let us down Apple! Looking forward to the next update!

Thanks guys, with the comments given I am sure now this is not my hardware but FCPX itself and also not a bloated OS with too many apps, also my tests of reinstalling the OS and FCPX clean pretty much prove the point.
You saved me a few grand I can use elsewhere..
I will put off upgrading to the cylinder Mac Pro trash can until FCPX actually is fixed and works correctly..

thanks again
Kurt

Redifer wrote: ....FCP7 is always 100% instantaneously responsive. It always has been. FCPX NEEDS to be equally responsive in the timeline at all times. FCPX must currently have very poor or unoptimized code or something. They need to fix it pronto....

Unfortunately I agree with this. Even on small projects I periodically see inexplicable slowdowns where the UI becomes sluggish and laggy. Restarting FCP X temporarily fixes it, which indicates it's a problem within the process: memory fragmentation, memory leak, handle/object leak, etc.

This doesn't mean the problem is within the FCP X code itself -- it could be certain plugins or codecs. But for the customer it's still a problem.

In software design there's always a debate about whether plugins should be handled "in process" or "out of process". Loading them into the address space of the main process gives better performance but any misbehaving 3rd party code can derange the entire process. Loading them out of process is more resilient to failure but requires inter-process communication which is slower.

This issue was recently played out in tabbed browser design where initially most browsers ran each tab in process. They found a single malfunctioning tab would take down the entire browser, so most now use process-per-tab design.

The architect of the core product must use design features which protect stability and integrity, not just assume all parties write perfect code. The steps may include special validation suites, out-of-process design for add-ons, instrumented code which can be activated at the customer site to rapidly gather more information, or using live remote debugging. These items should have preeminent position in development priority, else the reputation of the product becomes so tarnished that no new feature will save it.

As customers our best step is communicate with each other, share notes and try to isolate the procedural, codec and plugin scenario causing the problem.

One of the most obvious delays with some plugins is when the plugin contains a video file.
This will cause long delays if 'all' is selected when switching inside the effects browser (switching between filters, transitions, titles, etc..)
So this happens when the plugin dont need to be actually used in the timeline.
If it is used, maybe other delays?
If the plugins could alias somehow, that may fix that issue.

But with my tests I mentioned at the start of the post, No plugins were installed.
Clean OS install with no other apps other than a new install of FCPX

I should add..
One good thing out of this test is that FCPX did not take that bad of a hit when tested with a million plugins and a million other apps on the OS... vs a clean OS and no plugins.

performance within FCPX was better on a clean OS and no plugins, but not that much.

This is a benefit of mac OS's as compared to a window OS, the apps (for the most part) remain within there own bundle and there is not too many 'dll's' (from my windows days) scattered throughout the OS

Kurt

dkag7 wrote: ...with my tests I mentioned at the start of the post, No plugins were installed. Clean OS install with no other apps other than a new install of FCPX

That is good from the standpoint of a simplified, hopefully reproducible procedure. A portable, consistent replication scenario greatly facilitates getting bugs fixed. Even if the reproducibility is only 1 in 5 times, provided the overall procedure is straightforward and doesn't require a huge amount of data, that is still good.

From a software engineering standpoint, even a semi-reliable replication scenario is vastly better than trying to deduce a failure from looking at a crash dump, custom instrumentation code or live remote debugging.

the duration of the timeline is not the problem!
but the items on the timeline.
you always said you have no problems
please upload a video when fcpx's timeline has over 3000 items on it
(about 1000 video items and 2000 audio items)
then zoom in an out the timeline, and edit something on it, then playback
you will find the performance is very bad, it's very lag
but fcp7 is not

or you can upload the video (with a clock on the screen plz )to show it's not

yes, I've a good reason to tell my boss to change fcpx to avid

we've got 10 varicam35, and avid is going to support avc ultra at once

hahahaha

what about avid running on the ultimate mac pro cylinder?

I can tell you if you have the ultimate mac pro cylinder with 16gbps fiber raid (very high iops)

you will still feel very lag when controlling the over 1500 items timeline!

(and maybe over 900 audio items attach on the video!)

and it will always read the waveform whenever you have read it or not if you click the audio in the inspector!
Please do not read the waveform when I don't need it!

If fcpx can resolve these 2 problems, it will be faster enough!