fbpx
✎ Latest Free FCPX Effects
Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. 7 hours 55 minutes ago

pszilard wrote: That’s very interesting. Would you care to mention which, as it might help others (and me) in case we have the same loaded.


That one plugin was Imagenomic Portraiture for video: imagenomic.com/Products/VideoSuite

However I've examined other people's crash logs which show plugin code within FCPX address space, even though they had not applied it to a timeline. I don't remember which ones.

I'd say just not applying the plugin or 3rd-party effect is about 80-90% safe. But simply having it installed (though not applied) has some risk, especially if you have a ton of them.

This will hopefully be improved with the FxPlug 4 architecture that runs plugins in a separate, isolated address space. But plugin developers must re-write their code for that. Realistically that may not happen until after the ARM transition.

Read More...

Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. 10 hours 21 minutes ago

pszilard wrote: Not sure if the OP was talking about just having plugins installed, but not applied to the timeline, OR having many plugins actually applied.

I have a ton of plugins installed, but rarely use more than a handful on any one timeline. I expect that should not matter. Can anyone confirm this?


Normally a slowdown happens from *using* the plugin. Less commonly, just having the plugin installed can cause performance or stability problems. I have had a few FCPX crashes caused by a plugin which was installed but not used in any project. This was confirmed by the plugin mfg, also the crash report showed their code inside FCPX address space.

Read More...

Joe M. replied to the topic 'Exported files won't open in Premiere Pro' in the forum. yesterday

There is a 10.4.10 FCPX bug fix update out today. You could try that and see if it makes any difference.

Read More...

Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. yesterday

KScha wrote: ... My current practice to to load all clips into the library when I import them. I understand that keeping them out of the library and into a separate source folder my help with speed and performance. Any thoughts on that?...


That will only make a difference if you have an IO-bound problem. If it is CPU or GPU-bound, that won't help. The fact you mention periodic "beach balls" and lots of 3rd-party effects (inc'l Pixel Film Studios) implies it could be compute-bound. A chain is only as strong as the weakest link. If the weak link is computation from (a) Plugins or (b) A difficult codec, then improving I/O won't help.

That said, even if IO is *not* your current problem, it's generally a good idea to have the library and cache on a separate (preferably SSD) drive than the media. The IO stream to library and cache includes lots of small random IOs which conflicts with the large sequential IOs required of media.

If your system drive is HDD or Fusion, you definitely don't want the library, media or cache there. If it is SSD, in theory there's sufficient IO bandwidth, but typically the internal SSD isn't big enough so it's a moot point.

To place cache on a designated location, select the library in FCPX and in the Inspector at upper right, pick Storage Locations>Modify Settings>Cache>Choose, and pick an external SSD drive. Note if on Catalina and not running 10.4.9, there is a bug which can hang FCPX if you try to create a folder in that dialog. To workaround that create the folder in Finder, do CMD+I, scroll to bottom and grant Read/Write access to user "Everyone", then click the gear icon and pick "Apply to Enclosed Items". After that use FCPX to designate that folder for Cache.

It is more likely you have a compute-intensive issue due to the 3rd-party plugins. Do the previously-stated timed tests about rendering the timeline vs exporting, both with and without effects, to determine where the problem is.

If you create proxies it will probably improve performance a lot. Ripple Training has an excellent tutorial on FCPX media management: www.rippletraining.com/products/final-cu...ent-in-fcp-x-10-4-9/

Read More...

Joe M. replied to the topic 'Cannot load library from external disk - always empty' in the forum. 2 days ago

As a contingency, copy all FCPX auto-backups to external media. By default those are in /Movies/Final Cut Backups.

Then run Disk Utility First Aid on your external drive. Observe to see it runs without errors. The disk format of all drives holding FCPX media and libraries should be HFS+ (Mac OS Extended Journaled), or APFS, not ExFAT, NTFS or anything else.

If your library is on your system drive, make sure you have at least 20% free space on that drive.

As Tom said, try opening a backup library. You can do that within FCPX or by navigating to the above-listed backup libraries in Finder and double-clicking on them.

If you are on Catalina, make sure FCPX has full disk access. Go to System Preferences>Security & Privacy>Privacy, unlock it, scroll down to "Full Disk Access" and make sure FCPX is enabled for that.

If you select an event, it should either show existing clips or red "missing media" clips. You showed a screen cap inside your library, however it was at the top level, not within the event. Inside the event within the Original Media folder should be symbolic links to each media file contained on your external drive. Are those symbolic links present?

Note those symlinks will only be present in the original library, not the backup libraries. Apparently the backups store only "inode" locators for the external media files, then after loading the backup library in FCPX the symlinks are regenerated. For that to work the external drive must be on line, and have the same volume name as before.

Read More...

Joe M. replied to the topic 'Thumbnails in Multicam cripplingly slow' in the forum. 2 days ago

tijuanakez wrote: 2011 iMac 3.4Ghz AMD Radeon HD 6970M 2048 MB.
So definitely not the greatest by todays standards....


You said you have a dozen angles in your multicam? Is that 4k or 1080p? Is it H264? Are you using proxies?

You have a 2011 iMac 27 with a 4-core 3.4Ghz i7 ("Sandy Bridge"), and a 2GB Radeon HD 6970M. That machine has FireWire, USB 2.0 and Thunderbolt 1 ports. How is your SSD connected? Unless it's a Thunderbolt device it seems it would be slow? If you run Blackmagic speed test on that SSD, what is your performance, plus the performance of any other internal or external hard drives?

The Sandy Bridge CPU had the very first version of Quick Sync, so if you have any H264 content, the hardware acceleration may be limited. Just between 2015 and 2017 iMacs, Quick Sync had a 2x performance increase.

Also what version of MacOS and what version of FCPX are you running? There was a significant performance increase in FCPX starting with 10.4.8 due to Metal optimization, also more in 10.4.9. If your iMac can't run those versions, that is another possible source of performance issues.

If I was editing a 12-angle multicam on my 10-core iMac Pro I'd be using proxies, and I'd have the library and cache on a 1,000 MB/sec dedicated SSD via USB-C or Thunderbolt. I realize you must make do with what you have, and you can still do valuable work on the 2011 iMac. My co-worker had a 2010 iMac until recently, and he edited 1080p H264 content. However we have spent a large amount of time investigating a presumed FCPX performance issue which might have a significant hardware performance constraint.

Read More...

Joe M. replied to the topic 'Does having too many plugins slow down FCP?' in the forum. 2 days ago

KScha wrote: ...struggling with slow rendering... I'd assume that I should fly through most of the projects I do (most 3 - 10 min in length) but it seems so slow sometime and I do get the beach ball on occasion...


When you say "slow rendering", do you mean exporting to a file or rendering the timeline to cache or both? Or do you mean scrubbing through the timeline is laggy and slow?

Can you give more info about what codecs from what cameras? Is it 4k? Is it H264? Is it single-camera or multi-camera? If uncertain, play a couple of clips in Quicktime Player and do CMD+I. That will show you the media and codec info.

Re beach ball, that is not really an indicator of slowness but that something is wrong or software or plugin is poorly written. A beach ball is not a "busy indicator" but means the app has quit responding to events for several seconds. Ideally you should never see a beach ball, because a well-written app either does asynchronous (ie non-blocking) API calls or offloads time-consuming tasks to other threads. However there are limitations in MacOS and related frameworks which require that certain APIs be called from the main thread which also runs the app's UI.

Further complicating this is the programming and threading model in the current FxPlug 3 framework which plugin developers use. In this scheme all plugin code and threads run within the FCPX address space, so a plugin bug or simply a CPU-intensive plugin code path which does not properly yield every few seconds can cause a temporary beach ball. As plugin developers migrate their code to FxPlug 4, this problem should be reduced: developer.apple.com/documentation/profes..._minor&language=objc

For the above reasons it's important to be *very* selective about what plugins you install and use, and also keeping those plugins updated.

It can help to isolate performance problems between several areas: user interaction (e.g navigating and editing the timeline), rendering and exporting. Also isolate whether effects are involved.

The first step is disable background rendering in FCPX preferences, then delete all cache files via File>Delete Generated Library Files>Delete Render Files>All. After that select all clips in the timeline with CMD+A, then do a one-time render of those via CTRL+R. Do not use the machine while that runs.

Once it finishes no render dots should show above the timeline. Scrub back and forth in the timeline and evaluate performance. If export was slow before, try exporting the pre-rendered timeline using this preset: File>Share>Mater File>Settings, Format: Computer, Video Codec: H.264 Faster Encode, Resolution: 1920x1080.

If any problems with those, state the results. If your source material is 4k H264, that can be sluggish to edit on almost any Mac. In some cases you may need to create proxies or optimized media.

If you have (or suspect) very compute-intensive plugins such as Neat Video, update to the newest version which is faster. If still unsure of plugin contribution to your performance problem, make a snapshot copy of the project. Right-click on the project icon and pick "Snapshot Project" (in 10.4.9), then open the snapshot. Select all timeline clips with CMD+A, then remove all effects using Edit>Remove Effects. Navigate the timeline, and do the above export. Time that export and compare to the one with effects. That helps determine what % of the problem is simply a difficult codec vs what % is from effects.

FCPX itself has had recent performance upgrades, starting with FCPX 10.4.8 and continuing in 10.4.9. For some workflows, codecs and effects, it is significantly faster than 10.4.6 or earlier. If you have not upgraded to these versions, consider doing that. As always it's wise to fully back up everything before upgrading (especially FCPX libraries). In /Applications, use Finder to right-click and duplicate the Final Cut Pro.app file. That allows easy roll back to the previous version if you encounter a problem.

Read More...

Joe M. replied to the topic 'Thumbnails in Multicam cripplingly slow' in the forum. 3 days ago

tijuanakez wrote: So each time I want to open up my Multicam clip and make some changes, it opens blank and starts recreating all the thumbnails again. There's a dozen or so angles and most are composites so it means I have to wait 10 secs each time I want to see where things are to make an edit...Is there any way to pause the regeneration of thumbnails or even just use a poster frame for thumbnails?...


You can temporarily turn off thumbnails (inc'l generation) by setting "Clip Labels Only" which is CTRL+OPT+6, or CTRL+OPT+1 (waveform only). CTRL+OPT+1 through 6 sets various view options.

Unfortunately you cannot retain existing thumbnails and turn off only generation of new ones.

For clips in the Event Browser, thumbnails are initially generated upon import. They are regenerated under some conditions if the filmstrips are resized either vertically or horizontally. They are not all pre-generated en masse, but only sufficient for the current Browser display. As you scroll down in the Browser more are generated.

Timeline thumbnails are generated when the clip is added, and under some conditions when resizing the timeline.

Both thumbnails are stored by default in the library in EventName/Render Files/Thumbnail Media. Examination of the I/O profile during thumbnail generation indicates it's doing a lot of small random writes, roughly around 10K to 20K bytes. On a mechanical drive this will be slow, so if the cache was placed on an SSD that might help.

I previously sent an enhancement request to Apple for more control over thumbnail generation. In LightRoom you can control pre-generation of previews, trading off resolution vs time to create. However in keeping with the FCPX design philosophy, I think Apple wants a "no config" automatic algorithm for thumbnail generation.

Aside from the thumbnail issue, it's generally a good idea if possible to place the library and cache on an SSD. The library itself is internally a SQLite database and involves a lot of small random IOs. You can designate a location for cache by using the Library Inspector>Storage Locations>Modify Settings. Note on Catalina, FCPX versions before 10.4.9 might hang if creating a new folder for media or cache within the Modify Settings dialog. The workaround is first create folder with Finder, then do CMD+I and grant read/write permissions to group "Everyone", the click the gear icon to apply to "Apply to Enclosed Items". This bug is fixed in 10.4.9.

Certain codecs and import modes can worsen performance of thumbnail generation. In particular if bare MTS files are extracted from an AVCHD package and imported using "leave files in place", thumbnail generation can be extremely slow.The solution is transcode to optimized media or first re-wrap with EditReady2 before import.

If using "Clip Labels Only" view mode, it may seem difficult to navigate without thumbnails. However by using clip skimming you can generally find the location. In some cases with lots of connected clips or with a big multicam, it can be beneficial to assign a role color to tell the clips apart. For video-only clips a video role color can be assigned. A/V clips take the audio role color, so assigning an audio role color would be needed. That is the display mode Apple often uses in the FCPX ads: www.apple.com/final-cut-pro/

Read More...

Joe M. replied to the topic 'Compounding multiple audio clip slowing down FCPX' in the forum. 5 days ago

FCPX.guru wrote: ...Snapshots should not cause any slowdowns at all...


In my experience creating a bunch of snapshots might slow things down. It seems variable, based on project complexity, machine performance and where the library is located. If the library is on a fast SSD it seems less pronounced.

Each snapshot is another CurrentVersion.fcpevent database (like any other project). In theory a large # of projects need not slow things down. But according to the SQLite documentation, each open database consumes resources.

It appears FCPX may internally pre-open a certain # of projects, possibly to improve response time when one is clicked on. This is apparent because under some conditions it shifts to a deferred opening algorithm, where you suddenly see an "opening project..." status line, followed by a delay. This is when you don't click on the project -- it just does it.

I'm guessing they are trying to balance three things: (1) Cumulative overhead if all projects were internally pre-opened (2) Response time if they only opened projects on user action, and (3) A "no config" UI so it's fully automatic as it shifts between modes.

In my experience if you make more than about 20-30 moderate-complexity snapshots, it is more likely to slow down -- mainly when opening a library or shortly afterward.

IMO it's a good idea to have a "lean library" (no media or cache) located on a fast SSD. The cache should ideally also be on that SSD. The reason for separate cache is not performance (it would also be on SSD) but to keep the library small for easy file-level backup and it also streamlines deleting cache items like thumbnails, waveforms, and optical flow files which cannot be deleted using the FCPX UI.

Read More...

BillBridger wrote: C300 II footage shot in 4K, C-LOG3, Rec. 709

The footage looks flat, as you'd expect from LOG in the file browser, when imported into FCPX it looks flat while skimming and during playback but a second or two after I pause it gets a slightly darker look...


www.fcp.co/forum/4-final-cut-pro-x-fcpx/...i-log-footage#109977

Read More...

Joe M. replied to the topic 'Working with RAID storage or external SSD?' in the forum. 7 days ago

El Matadurr wrote: ...My current iMac throttles performance all the time due to thermal issues, and did so way before the inside became filled with dust (I can even see it on the inside of my screen). Holding out hope the next iteration has better cooling design, or even...god forbid...a way for users to get into the system to clean it out without having to break the glue seal.


Max Yuryev's tests show the 2020 iMac 27 has significantly improved thermals vs prior models. The 2014 (which you have) is unfortunately the worst Retina-era Mac from that standpoint. The 2015-2017 models were not much better but a little better. I think the 2019 was improved and the 2020 improved more. That was without major mechanical changes; not sure what they did but the reviewers report significant improvements.

But even the 2020 iMac 27 is not as quiet as the iMac Pro.

Read More...

Joe M. replied to the topic 'Exported files won't open in Premiere Pro' in the forum. 7 days ago

oldsoul wrote: I exported the same piece as ProRes and XDCAM...


Using your 1080p/29.97 test clip "Export Test - ProRes422.mov" I can reproduce the problem on Premiere 14.3.2 and 14.4.0 on two different machines. Examination of the video header with Invisor doesn't show anything obviously wrong: apps.apple.com/us/app/invisor-media-file...or/id442947586?mt=12

Your test clip imports OK to FCPX 10.4.9 and Resolve 16.2.6. In FCPX if I re-export that same clip to ProRes 422, then Premiere will take it. IOW if I process the clip in any way using any software, it doesn't happen.

Can you take your exported test clip, import it, then re-export it as ProRes 422 and check that with Premiere? That may help determine if it's related to your original source clip. If it only happens on your machine, then it might be a plugin, 3rd-party effect, etc. But normally that would not create an apparent encoding issue in a ProRes output file.

I also tried simply re-wrapping your test file with EditReady2, and that also avoids the problem. That might be a temporary workaround. Since no re-encoding happens, it is super fast: www.divergentmedia.com/editready

Since the error happens on the Premiere side, IMO Adobe needs to take the lead initially. They have the source code and can run their product under a debugger and determine why it's throwing that error when importing that file, when other NLEs don't do that. We see the simplified error "unable to open the file on disk", but at the source code level it is failing a specific check or series of checks. It might be getting an error return from a call to a decoding framework. Without source code (which only they have) it's impossible to tell if it's an issue with encoding, decoding, ProRes specs, software framework, etc.

If Adobe's examination shows it's an issue on their side they can fix it. If it shows it's an FCPX encoding problem, their developers need to talk to FCPX developers. They have each other's contact info for cases like this.

You can initiate this process by starting a support case with Adobe, and sending them the test file. It would help if you could make the creation of the problem clip happen on another machine. Given your output clip we can see Premiere raise the error on other machines, but we cannot recreate that bad clip.

Without getting any deeper you could also try some basic troubleshooting steps -- not because they are likely to fix the problem but because they are easy to take and have fixed other problems previously.. Examples:

- Reset FCPX preferences (item 11): support.apple.com/en-us/HT203477

- Disable background rendering in FCPX preferences, delete all render files in the library via Files>Delete Generated Library Files>Delete Render Files>All, then select all timeline clips with CMD+A, and render them to cache with CTRL+R. After that export your test clip, and try the Premiere import test.

- If it still happens, right-click the project and select "Snapshot Project". Open that snapshot, select all clips with CMD+A, then remove all effects with Edit>Remove Effects. Export that and try to import to Premiere. If it works it could be some interaction of effects and the source media.

Read More...

Joe M. replied to the topic 'Exported files won't open in Premiere Pro' in the forum. 7 days ago

I tried the latest version of Premiere 14.4.0 on another machine, and it loaded a 4k ProRes 422 file from FCPX 10.4.9 just fine.

Many Premiere users have reported that error "we were unable to open the file on disk" with various file types, not just ProRes. If that same exported ProRes file will play in Finder and import to Resolve, that might imply it's a Premiere problem or a system problem such as missing Adobe support files.

However it's also possible Apple made some permissible change to their ProRes encoder and Premiere isn't handling it properly. It can't be a widespread problem because ProRes is a common post-production infrastructure. Worldwide probably hundreds or thousands of files per hour are being sent between Premiere and FCPX.

To rule out the possibility of a specific source clip triggering this, if you could reproduce it using a very small source clip then upload it to DropBox, etc, I could test that on several machines.

Read More...

Joe M. replied to the topic 'Exported files won't open in Premiere Pro' in the forum. 7 days ago

What is the exact error that Premiere gives?

Read More...

Joe M. replied to the topic 'Exported files won't open in Premiere Pro' in the forum. 7 days ago

On my machine Premiere Pro 14.3.2 opens the UHD ProRes 422 file from FCPX 10.4.9. If the destination machine is on Windows or an older version of Premiere there might be differences.

FIrst I suggest simplifying the scenario. Just take one short test clip, export that to ProRes 422 and see if will import to Premiere. If not take that same test clip and import it to the free version of Resolve, then export it to ProRes 422 and see if Premiere will accept that.

Try putting the file in a different location to make sure it's not a permissions problem. In Finder do CMD+I on the file, scroll down to the bottom, unlock "sharing and permissions" and grant group "everyone" read/write permissions on the file and folder it's in. Make sure it is a local, directly-attached hard drive not a NAS drive, cloud drive, etc. Try the import to Premiere on the same physical machine, not a different machine.

It is likely a config or permissions issue, nothing related to ProRes or the FCPX encoder. You get the same error on H264 exports. If Premiere could not import any ProRes or H264 file from FCPX 10.4.9, we'd have known that long ago.

Read More...

Joe M. replied to the topic 'Working with RAID storage or external SSD?' in the forum. 7 days ago

El Matadurr wrote: ..Speed will only improve further when I can eventually get an ARM iMac with Thunderbolt 3.


The ARM iMac 27 is probably a year away. I'm sure it will be good but if you need a machine sooner, the 2020 base-model 8-core iMac 27 is (for a Mac) relatively inexpensive and vastly faster than your 2014 iMac.

Read More...