No Peak data, but slowly rebuilding…?

[Joe Marler]

The current version is 10.4.10. It has significant performance improvements over 10.4.6. In general 10.4.10 is not buggy but if you have old plugins which have not been updated, those can cause problems.

While it’s not usually a good idea to update in mid project, this can often be safely done with the proper procedures. You simply need to have backup copies of your libraries and in Finder duplicate and rename the 10.4.6 version of Final Cut Pro.app in /Applications. That allows an easy safe roll back if any problems.

All plugins should be first updated, *especially* those from CoreMelt. Here are their installers: https://coremelt.com/pages/downloads

Catalina is not required to FCPX 10.4.10, Mojave is OK.

If your libraries are very large due to containing media or cache, then duplicating them is difficult. The solution is only use “lean libraries” which have external media and external cache. Cache can be placed in a user-designated folder by using the FCPX library inspector, Storage Locations>Modify Settings>Cache.

Having cache external accomplishes several things:

(1) Keeps your library smaller, thus allowing easier duplication for backup.

(2) The small library can be more easily located on an SSD which is much faster for the random I/O required for the library database.

(3) Puts all cache items external for possible placement on an SSD or other fast drive. Since waveforms and thumbnails are stored in cache, this can really help performance.

(4) External cache allows easy deleting of the cache bundle from Finder. This sometimes fixes problems with black thumbnails or red waveforms. The waveforms and thumbnails are not deleted by the command File>Delete Generated Library Files>Delete Render Files>All. However if cache is external you can safely shut down FCPX and delete the cache which is in a folder you specify. You delete the bundle named LibraryName.fcpcache. It will be automatically rebuilt.

From a performance standpoint you don’t want the library on the same drive as media. Library and cache can be on the same drive if it’s a fast SSD.

Disable background rendering in FCPX preferences. If needed you can render the timeline by selecting all clips with CMD+A, then render with CTRL+R. This avoids continuous rendering and build-up of discarded render files.

[Alan Langdon]

Thank you again, Jo! Saw your post on fcp.co.

Here’s what I replied there, for other Cow users:

Thank you Joe for the rundown of so much sound advice. I have been using 90% of those procedures you mention, so it’s also good to know I am on the right path. It’s very strange, for me, how it takes SO long to rebuild these waveforms. I have left FCPX alone for several hours, several sessions, and it still is rebuilding them. Every now and then a clip previously with red waveforms becomes complete. One by one, very slow, and I am on a not-so-slow 2019 Mac mini.
About Catalina and FCP 10.4.10, I di not know there was that update, will look into installing both on my 2017 MBP and see how they go. I would love to upgrade fully, but mid project and with 32-bit apps that I still like to use, I will not upgrade yet on my main machine (Mac mini).
Thank you!

[Joe Marler]

Normally it shouldn’t take hours to generate waveforms. On my iMac Pro running 10.4.10 with media on a 4-drive OWC Thunderbay 4 in RAID-0 and the library/cache on the system SSD, I imported 466 .wav files which totaled 273 GB. This took about 15 min to complete waveform generation.

I then did another test of importing 686 .mp3 files totaling 16 GB. They were scattered throughout a 48TB OWC array; I located them by doing a Finder search on *.mp3, selected them then imported via drag/drop with FCPX set to “leave files in place”. That went through three phases:

(1) Validating 686 .mp3 files for import (5 min)

(2) Processing files for import (10 min)

(3) Waveform generation (22 min)

Total time from import start to completing waveform generation: 37.5 min.

Observing Activity Monitor’s IO tab during phase #1 and #2, it was doing a very high read rate of over 6,000 per sec. These were certainly cached reads using the MacOS “Unified Buffer Cache” which uses surplus RAM to cache disk I/O.

In my .wav import test, the average file size was quite large. During the .mp3 import, the average file size was smaller. In Activity Monitor’s IO tab if you compare read in/sec vs data read/sec, this gives a rough approximation of IO size. Likewise for writes. In general it appears FCPX does lots of small reads, then transitions to a phase where it’s doing lots of small writes, likely writing waveform and peak data to the FCPX cache.

If your library, FCPX cache and media are all on the same mechanical disk, those IO streams may interfere with each other, slowing the process. This is similar to copying multiple large files between two mechanical drives using Finder. It is normally faster to copy them sequentially vs in parallel.

During waveform generation, if the Event Browser is set to filmstrip mode, it will prioritize non-generated waveforms on screen. If you keep scrolling down during that process, it might conflict with background waveform generation. To avoid this consider putting the Event Browser in “list view” while waveform generation is happening. OPT+CMD+2 toggles between filmstrip mode and list view.

In general if you have a large production using thousands of clips, you want higher-end hardware. You don’t need a $40k Mac Pro but I’m unsure if a Mac Mini with all media on a single mechanical drive is adequate. At a minimum you want the cache and a lean library on an external SSD, preferably something like this Helix 2TB which can do 1,000 MB/sec and doesn’t have thermal slowdowns under sustained writing: https://www.amazon.com/dp/B07YCR1S3K/

After the media is ingested and organized, and after initial editing is well underway, then you may start applying effects. Since those are GPU-based, the lack of a discrete GPU might be a problem. In theory you can add an eGPU but those don’t work as well as an internal GPU.