Quick & Snappy FCP with timelines above +/-45min

Hi all,

I've been using FCP since the beginning of this year for the first time on several projects, and although I like editing in it, I seem to have difficulty keeping FCP fast on projects that are somewhat longer than +/-45min.

I know about plugins and titles slowing it down, and when I remove them it does make a difference. But still a 60min timeline with only 1080p prores footage and a good amount of sfx (all in 48khz / .wav) feels quite less responsive than a similar timeline of 15min (even though I'm on a Mac Studio).

I've read about people editing in reels of 20min, and then combining them later on when you want to view the film.
This looked like a good idea but when I tried to combine reels of 20min via copy pasting clips between timelines, they don't come over (is there a limit to the amount of clips that can be copied in one go from one place to another in FCP?), and also trying to make a compound clip of a 20min reel gives me a classic mac system error sound.

I come from Avid and I'm used to being able to have projects with a lot of material open without a problem, so I'm curious how all of you keep FCP running smoothly as possible.

Thanks in advance,
Erik

Erik ten Brinke wrote:

Hi all,

I've been using FCP since the beginning of this year for the first time on several projects, and although I like editing in it, I seem to have difficulty keeping FCP fast on projects that are somewhat longer than +/-45min...

Erik, can you roughly characterize your timeline? How many clips, how many edits, etc?  Better yet, just upload to me a project XML. I cannot see any of your material but I can analyze the timeline structure. I have been investigating some FCP performance issues for some time.

The short answer is we should expect FCP to be responsive and fairly fast on "longer" timelines, especially up to 60 minutes. However there can be vast differences in timeline complexity and in the computational burden imposed by various codecs and effects. 

My current assessment is there might be some issues, but in the severe cases I've examined, they also appear in Resolve. Some unresolved questions include:  is FCP been getting worse vs past versions, is it related to FCP or MacOS, or is it increasing timeline complexity?

I will post some info on another thread on this forum, then I'll post a link here.

You can upload your project XML to this secure write-only site:  www.dropbox.com/request/8fWpy4IApBI1F83OsFn2

Hi Joema,

Thanks for helping out!
I've dropped the project XML in your dropbox

Best,
Erik

Erik, I downloaded and examined your project XML. It is 1 hr 20 min, complex but not excessively so. It contains a modest amount of effects, mostly built-in. There is a long adjustment layer on top (I can't see any Fx on it).

On my M1 Ultra Mac Studio running FCP 10.6.5 and Ventura 13.3.1, it runs mostly OK, albeit without media. However, major issues (if any exist) will often appear even without media, just from loading the project XML.

I could trim clips, drag/drop large sections, create a compound clip of either sections or the entire timeline, and copy/paste that compound clip into a new project. In that new project, I could decompose the compound clip using SHIFT+CMD+G. It would go to a beachball (aka "spinning wait disc") for a little while, then it would complete.

So it mostly worked, although when I repeated variations of the above procedure several times, FCP hung once, then upon restart and opening the project, it crashed. 

I took a spindump of the hang, and a study of that indicates it encountered problems while updating the UI for the inspector, doing something related to video channels (probably meaning various video "lanes"). It seemed to get stuck in a loop while trying to create and update UI components, such as sliders and other controls.
The issue might be related to a Motion Effect that is being loaded in the background, which causes the application to update the UI components, resulting in a deadlock or an infinite loop.

The crash dump following the relaunch of FCP referenced an "anchored generator component." In FCP software design parlance, "anchored" means a connected clip. So that could imply something related to the adjustment layer (which was a generator) involved in the crash. 

I mention the above just to inform you. This does not mean you've done anything wrong. It could be an artificial side effect of my not having media or references to non-existing titles, Motion templates, or effects.

Can you provide more specific details about what aspect of FCP is slow on timelines above 45 min? Are certain actions worse than others? By "slow", do you mean a bit of lag, or frequent 10-second beachballs? Or do you mean the export time becomes exponentially slower?

Make sure your library and FCP cache are located on an SSD. Ideally, turn off background rendering, and render the timeline or sections of the timeline manually, as needed. Select the clips or the entire timeline with CMD+A, then render those to cache with CTRL+R. That said, any modification of an adjustment layer will cause all clips and effects covered by that layer to become uncached.

It appears that all your media and proxies are external to the library, which is good. 

You are apparently using the MotionVFX mDocumentary plugin. I don't have experience with that, but MotionVFX is a good company and their products are high quality.

It should be possible to copy/paste (for example) 30 min sections of your project to another timeline, either all clips or as a compound clip. 

As a standard precaution, periodically make a file backup of your library by duplicating it in Finder. That will be easier if the cache files are stored outside of the library. That can be done by selecting the library in the left sidebar, then in the Inspector select Storage Locations>Modify Settings>Cache and give it a folder. Subsequently all cache files, optical flow files, etc. will be stored in a bundle in that folder. That keeps the library smaller plus provides a safe method of deleting all generated files. You can safely delete that bundle, but do that while FCP is down.

In addition it's a good idea to periodically export a library XML and a project XML of your main project, and keep versions of those. That provides yet another fall-back method in case of problems.

From a performance standpoint, in general, FCP should remain relatively quick over a wide range of conditions. That said, there are certain timeline complexity parameters where it can get slow. Those are difficult to define in simple terms, and I'm studying that. In one severe slowdown case I recently examined involving a highly complex timeline, I exported an XML, imported that to Resolve Studio, and it was also very slow -- on a M1 Ultra Mac Studio. 

Thanks Joema for the extensive reply.

Ah that's funny, I cannot create compound clips from large portions of the timeline. Maybe this is a library issue.

By slow I mean that it's mostly a bit laggy, not really a lot but compared to a 15min timeline where everything I touch changes instantaneously, and not +/- 0,5s later, it is. Sometimes I get spinning beach balls where I need to wait a minute, or restart FCP entirely (once every hour or so).
Especially this 0,5s latency creates the feeling that you're not in touch or connected to your work, which I find crucial.

Also when I try to open a Smart Collection on the root of the library (for example "B-Roll Drone", FCP starts to load other sequences / projects that I don't need to be pre-loaded in the background because I don't need to acces them. Small things like this cut off the time you gain by working in the magnetic timeline, since this happens quite a lot.

Think I might stick with FCP for smaller projects and stick to Avid for larger ones for now.

I am still very much hoping Apple is working on some big rewrite or a serious feature update for FCP and is not letting it slowly die off

Erik ten Brinke wrote:

...I cannot create compound clips from large portions of the timeline. Maybe this is a library issue...

I can't explain that. It should work. However the timeline is complex with many connections. There might be some magnetic timeline rules about what clips are allowed in the compound clip. 

Erik ten Brinke wrote:

...By slow I mean that it's mostly a bit laggy, not really a lot but compared to a 15min timeline where everything I touch changes instantaneously, and not +/- 0,5s later, it is..

Timeline update performance can degrade on complex timelines. The skimmer normally remains fast but if you try to trim a clip or drag/drop a clip, there can be some lag. Questions include what degree of that is expected, is it normal, and did it always do this in previous versions or has some lag gradually been introduced which only appears in certain scenarios? I am studying this but it is difficult and time consuming.

Erik ten Brinke wrote:

...Sometimes I get spinning beach balls where I need to wait a minute, or restart FCP entirely (once every hour or so)...

From Apple's own application design standards (reiterated during various WWDC talks), that should not happen. A complex app like FCP may have dozens or a hundred threads. However any app has a main UI thread, aka run thread. That thread is responsible for processing user and system events and updating the UI. If longer-duration computation is required, it is supposed to delegate that to other worker threads, inform the user via some UI method that background work is happening, and maintain the UI responsiveness. 

If the app undertakes time-consuming work and quits servicing events, after a few seconds a MacOS component called "Window Manager" notices this and changes the cursor to a beachball. From an application design standpoint, that should not happen, or should only happen very infrequently and briefly. 

In cases I've examined, both FCP and Resolve do lots of computation on the main UI thread instead of delegating that to worker threads. However FCP does it more,  and can get bogged down in single-threaded work recursively traversing complex object hierarchies. This cannot be fixed with a simple update but requires rearchitecting the product. See this XCode Instruments profile from the same project in FCP and Resolve, both taken on an M1 Ultra Mac Studio:  joema.smugmug.com/XCode-Instruments-trac...erformance/n-tBwgCJ/

You should not have to restart FCP every hour or so. You could check the "memory pressure" graph in Activity Monitor's memory pane, to see if a memory leak is happening. If the graph is green that is OK. If it's yellow (or especially red) that is not OK.

Erik ten Brinke wrote:

...Also when I try to open a Smart Collection on the root of the library (for example "B-Roll Drone", FCP starts to load other sequences / projects that I don't need to be pre-loaded in the background because I don't need to acces them...

Each event in a library is composed of a SQLite database, and each project, snapshot or duplicate is also a separate SQLite database, each containing eight tables. Some of those tables may contain many thousand rows of information about media, edits, effects, etc. Basically, any time you do anything, many rows are added or modified.

Starting with FCP 10.2, the ability to search an entire library was added, called a library smart collection. To execute that search requires it open and scan all the SQL databases for each event and apparently for each project. The  more projects, snapshots and duplicates you have, the more delay can happen.

Each SQL database connection has overhead, so they can't just leave them all open. They are trying to predict by some algorithm the projects (hence databases) you will need and pre-open those for better response. However that prediction is imperfect, so you see the "project opening" delays. Ideally, you could configure that or specify which ones, but an FCP design goal is to minimize config pages, otherwise you eventually end up with Resolve which has a 4,000 page user manual. But there should be some happy medium.

Erik ten Brinke wrote:

...I am still very much hoping Apple is working on some big rewrite or a serious feature update for FCP and is not letting it slowly die off

It was a revolutionary product, but IMO it needs rewriting for architectural reasons and to harness new frameworks and methods. I hope that happens in the not-too-distant future.

Memory is almost always on yellow and lots of times it's in the red.
Working from a very fast external NVME drive of 4TB with 1TB free. Internal SSD 250gb free.

Will stick with Avid for now with larger projects.

Thanks for all the help Joema!

Erik ten Brinke wrote:

Memory is almost always on yellow and lots of times it's in the red. Working from a very fast external NVME drive of 4TB with 1TB free. Internal SSD 250gb free.

Will stick with Avid for now with larger projects...

It should never be red. That indicates a possible memory leak. IOW a code path within FCP is allocating RAM and not releasing it. Over time the memory consumption increases, slowing down the app. IOW the graph is not red because FCP is overloaded, it's red because something within the FCP process is malfunctioning. That could be Apple's code or the code of a 3rd-party plugin or effect.

On more recent Apple Silicon versions of FCP they mandated that all 3rd-party plugins be rewritten using the FxPlug 4 framework. That runs the 3rd-party plugins in a separate address space so they are less likely to crash FCP. However if those plugins malfunction (say from a crash or a memory leak) it still impacts things, even if FCP does not crash. But it was a useful improvement.

I can't remember what version of MacOS and FCP you are running. The early versions of Monterey had known memory leaks. That was resolved with later versions. I haven't seen that on the later versions of Ventura. This wasn't just seen by FCP, it could affect various apps.

Yes agreed about Avid. You must use what is necessary to get the job done.