[Joe Marler]

I don’t think there’s a keyboard shortcut for turning a roll on/off. However in the timeline index you can show roles and during playback enable/disable specific audio roles.

As always you can solo an audio lane using OPT+S.

There are shortcuts to mute or silence selected audio lanes (or ranges) and also to restore those to normal volume. Those are not by default assigned to a key, you must use the command editor to assign those: https://support.apple.com/guide/final-cut-pro/solo-and-mute-audio-clips-ver717f57b4/10.5.1/mac/10.15.6

Besides mute/unmute, you can disable/enable audio lanes with the V key. This is also range-based — you can drag a range over an audio lane with the R key and disable that range with V.

[Joe Marler]

Unfortunately I don’t know of any other solution. Re older stuff edited in 10.1.x, I thought 10.1 which was released in 2013 included the new library format. I thought 10.1 or later libraries could be opened in the current FCP 10.5.x version, but I can’t remember. The current FCP version definitely cannot open a non-updated project before 10.1.

If your really old stuff is in the old project and event format (pre-library) and hasn’t been updated since 2013, that is a problem since I thought the last version of FCP which could update that was 10.2.3 or thereabouts from 2016.

With the advent of 10.1 in 2013, Apple recommended backing up the library and FCP bundle before any upgrade. The purpose was to better preserve ability to run that in the future. However as you mentioned certain really old versions of FCPX might not run on a modern version of MacOS. I’m not sure what the limits are. https://support.apple.com/en-us/HT203010

You might have an exported version of the old timeline, and the media itself may still be available in the old event folders. Those media files could be imported to a new version of FCP and edited “by eye”, using the old exported timeline as a guide. I think the solution is either that or locate someone with an old archived (and runnable) version of FCPX 10.2.3 who could upgrade your old project. They might not even need the media and could possibly export an XML, send you the XML which you could then import and try to relink to the on-disk media. Just a guess.

[Joe Marler]

If you are actually referring to various versions of FCPX, you don’t need to remove or re-install the app. Given an older version on another machine, you can simply duplicate then rename the “Final Cut Pro.app” bundle to, say, “Final Cut Pro_10_4.app”, copy that to the new machine and double-click on that file to launch the old version. It is not necessary to rename the .app to the original name. If you double-click on it in /Applications it will still launch with the 10_4 name, or whatever.

The library versions are mostly locked to a version of FCPX, so an older version of the app will likely not open a newer library. Likewise if you open an older library with the newer app, it will upgrade it — which you may not want. When sequentially running different versions of FCPX, it’s best to close all libraries before closing the app. That way the next version you run won’t try to upgrade the previously-used libraries.

You can inspect the library version by doing right-click>Show Package Contents in Finder, then doing Quick Look (space bar) on the file CurrentVersion.plist.

You can have several different versions of FCPX and various library versions on the same machine under the same login account, but you must keep organized about what version you are running and what the library versions are. In Finder I usually rename the library with a suffix to indicate the FCPX version.

It’s best to have all libraries separately backed up before doing this in case you encounter a problem or accidentally upgrade an older library you didn’t wish to.

The above is mostly speaking of a fairly narrow range of FCPX versions on a newer version of MacOS. If you try to run a new version of FCP on an really old version of MacOS, that may not work. Likewise if the old projects contain effects, plugins or certain Motion templates, it’s possible they might not work right on a vastly different version of FCP.

If you are dealing with really old libraries, I think I think pre-10.1 libraries could be updated to 10.2.3, then those could be updated to later versions.

If the library version is 10.1 – 10.2.3, I thought those could be updated to the current version but I’m not sure. Maybe there was a cutoff version range where 10.1 – 10.2.3 could be upgraded to 10.3x but not later — just can’t remember; maybe someone else can.

[Joe Marler]

You mentioned both title safe lines and cross hairs. One step is to analyze where those came from. FCP title/action guides are thin and yellow. You enable them with View>Show in Viewer>Title/Action Safe Zones. If the ones you see in the video are not that color, style or thickness, they did not come from FCP.

Also FCP does not have a center cross hair overlay. Unless you added a 3rd-party effect, that did not come from FCP.

Many external recorders have configurable title/action safe zones and center cross hairs. Look at the files and see if the color & style of the title/action guides and cross hairs matches the style, color and thickness of Video Assist recorder’s on-screen guides. If so, that is where they came from.

Cameras also have those shooting guides, and if enabled for output it could be sent to the Video Assist and recorded. Compare the style, color and thickness of those guides in the camera vs the Video Assist recorder guides vs the files. That may reveal where they originated.

Are those in the original media files out of the Video Assist? If yes, FCP could not put those there, as it never opens the files for writing, only reading. If they are not in the original files but are in the exported files from FCP, and if the style/thickness/color indicates they came from the camera or recorder, how could they suddenly appear?

Maybe the Video Assist has a mode whereby it somehow writes those guides to the output file using alpha-channel transparency. If you edit using proxies, that doesn’t support alpha channel and they won’t appear. If you then switch to orig. media mode for final output, alpha channel items (inc’l title/action guides) would seem to suddenly appear, depending on blend mode. But that should require multiple layers in FCP, not just a single layer. Just a wild guess.

Try switching between orig. and proxy modes, also verify it happens on a single-layer clip within FCP and without any effects, titles or generators on the clip. Delete all cache files via File>Delete Generated Library Files>Delete Render Files>All. That’s in case some anomalous cache file is causing it. Also reboot the entire machine.

If a mirrorless camera, did you also record internally as a backup? If so you could check those files for comparison. If you did both internal & external recording, is it possible the files got mixed up and one group has the guides burned in and the other group does not?

[Joe Marler]

To my knowledge Color Finale 2 is written using Apple’s FxPlug 3 framework, and this will not run on Apple Silicon. Those plugins run within the address space of FCP, and Rosetta2 emulation cannot handle intermixed x86 and ARM64 code within the same process.

Plugin developers are re-writing their code for FxPlug 4 which will run “out of process” and should improve reliability. The plugin running in a separate firewalled host process will then communicate with FCP via an XPC. This also has other advantages such as improved threading and better render control. However until that is finished, any of the complex plugins using FxPlug will not be available for Apple Silicon. That includes Neat Video, Digital Anarchy’s Flicker Free, Imagenomic Portraiture, CoreMelt, etc.

It appears those developers are working hard on this and are making good progress, but it’s possible Apple may need to tweak some things in FxPlug 4.

[Joe Marler]

The pattern is reminiscent of a graphics hardware problem. What year and model of Mac, what version of FCP and MacOS and what GPU?

You can try running Apple Diagnostics, but it’s a rudimentary test and an error-free pass does not mean a clean bill of health. However if it finds something it’s usually significant: https://support.apple.com/en-us/HT202731

You can also try running the GPU-intensive BruceX benchmark. Make sure background rendering is off, and export to a ProRes 422 file: https://blog.alex4d.com/2013/10/30/brucex-a-new-fcpx-benchmark/

Also select each foreground and background image, and in Inspector (CMD+4 toggles), what is the blend mode for each one? Are the foreground and background images JPG, PNG, or what?

[Joe Marler]

Those are not folders but group categories. You probably have enabled a GROUP BY setting such as “by reel”, which is the number shown. In the Clip Appearance and Filtering menu (press button to left of magnifying glass at upper right of browser), select GROUP BY = None.

[Joe Marler]

Further testing shows relink has two main phases: “verifying files for compatibility”, and “relinking files”.

The first is the most time-consuming phase. It is doing many approx. 8 KB to 10 KB random reads, likely the video header of each media file. It is probably building an in-memory array which it then compares to the entry for each file in the SQL tables “Collection” and “CollectionMD”, which are contained in the bundle EventName/CurrentVersion.fcpevent.

During this phase it is doing only reads, not writes, and that constitutes the bulk of execution time on a mechanical array. If on an SSD the relative duration of each phase is more equal, likely due to the faster random I/O rate.

During the briefer 2nd phase “relinking files”, it is (1) rebuilding the pathname data in the SQL tables for each file, (2) rebuilding the inode for each file which is a secondary lookup method (3) updating the symlink for each file (all of which are in the library).

With 5,000 files comprising 11 TB on a 4-drive RAID-0 OWC Thunderbay 4 and with library on a dedicated SSD Thunderbolt array, the “verifying files for compatibility” phase takes 26 min, and the “relinking files” phase takes 5 min. Test system: 10-core Vega 64 iMac Pro, MacOS 10.15.7, FCP 10.5.

It is possible to determine the relative time spent for the 3rd step in phase 2 (symlink rebuild), since FCP will automatically do that if the files are moved or renamed on the same disk volume. You can rename or relocate 10,000 files within the same disk volume, and even manually delete all symlinks within the library. Upon re-launch FCP will use inode lookup to rebuild all symlinks within seconds.

This implies the relink bottleneck is not rebuilding the symlinks but (1) Fetching the video metadata from the header of each file, and (2) The array building and comparison phase. During portions of those periods the IO rate is very low and all CPU cores are low. This implies an algorithmic inefficiency, such as multiple threads blocked on a synchronization object.

This implies it may be possible for FCP development to greatly improve relink performance.

[Joe Marler]

If after copying all linked media to another drive, you maintain the original pathnames and volume name, it will not require relink. The normal procedure would be copy all media, eject original drive, rename new drive to original volume name, launch FCP, open the library and it will connect. In a hand-off situation you’d also copy the library itself to the new drive. The location of the library itself doesn’t matter, but the media files must be in the same relative locations and on the same volume name as the library expects.

Obviously if you ever plug in two drives with the same volume name, that can be confusing since Finder only shows the “friendly” name. The terminal command “ls Volumes” will show a uniquifier suffix added to the 2nd drive.

Ideally FCP should have a UI for altering the root volume name in the library, while maintaining the rest of the pathnames.

[Joe Marler]

1-3 hr to relink is interesting; I have relinked large documentaries including 8,500 clips and 220 hours of 4k material and it took about 45 min on a locally-attached OWC Thunderbay 4. That was several versions ago and there were some significant relink performance issues that I think have been improved since then.

The good news is by ingesting proxies for edit, later relinking to originals and using the new feature to then relink to proxies as proxies, it at least preserves the proxies. On a previous project it took me several days to regenerate proxies because proxy relink was not supported.

But you have an interesting point — if it takes up to 3 hr to relink, it would be nice to avoid that. If proxy-only import as proxies was supported it would help.

My question is if it takes 1-3 hr to relink, why? It shouldn’t take that long to enumerate 10,000 or so files and attributes. Much of the metadata is already indexed by spotlight, but if it had to actually read each file header for video metadata, that would still only be about 60 seconds. I just re-tested my 48 TB OWC RAID-0 array and it can do about 130 non-cached random 32 KB reads per sec. But FCP must match each of those against the stored attribute data in SQLite tables inside the library. If each of those is an indexed access, that also should be very fast. This implies there is some bottleneck in the SQLite access path or associated code for a relink.