FCPX And El Capitan

I entirely agree with Greg.

The AU plugins did not crash FCP X at all. El Capitan has a new system for validating AU plugins, and some plugins from some vendors had to be updated to make them compatible. That's why third-party vendors receive API's before any new release, so they can test their products with the new OS and, if needed, update their plugins. Most vendors have done this in time.

Only a small fraction of all Mac users use FCP X, and only a small fraction of FCP X users actually use these plugins. This means the few problems with plugins are insignificant to the vast majority of Mac users. So it's obvious that you cannot expect Apple to wait with releasing a new OS until every little plugin manufacturer has done his work.

- Ronny

That is a terrible idea if that is what Apple have decided, Apple own the product, they should ensure that at all times all plug ins are safe, tested, confirmed prior to allowing developers to publish. Maybe that is the problem, and what I fear, Apple not paying attention, then bad code creeps in, and ruins software.

I guess I should mention that any app sold through the App Store is reviewed by Apple for Malware and other issues, but you do not have to get all your apps there.
iOS / iTunes App Store is the only non-jailbreak place to get apps for phones, iPad, etc… and there Apple has much more control.

Hope this helps, Greg

With all due respect, you absolutely have no clue. This-party plugins cannot affect OS code. Period.

- Ronny

Well if anything Apple has tightened up security at least in the OS kernel / system code via Software Integrity Protection (SIP) in El Capitan. This prohibits any software from alternating the OS systems kernel code. SIP itself may cause issues with older software that attempts to alter this code, and from people like me who do it on purpose.
You can still disable SIP, but most; 99.99999999% of user won't and have no need too.

MsJ your complaints aren't warranted. I have used Macs since 1985 and the number of issues over the years does not equal one years worth of problems with any of my Windoz systems. Malware is very unusual on Macs. KPs are very unusual on Macs.
I have always said if you want to have problems with your computer, why pay money to M$ when you can install Linux for free? At least with Linux, you can fix it easily.

Developers have the responsibility to keep their software up to date. Apple is even pretty good with developer support.

Hope this helps, Greg

I don't know if this is related to El Cap or not. I have not upgraded to El Cap and will hold off until at least until iZotope plug-ins are ready. In preparation of upgrading to El Cap though I upgraded my iZotope "Ozone" and "RX" programs to the current versions since the older versions I had were not on iZotope's list for El Cap compatibility development.

I'm running OS X 10.10.5 Yosemite with FCPX 10.2.2

Now after upgrading them when launching FCPX I get the attached message. Clicking OK launches FCPX but I don't know how to get it to stop looking for this plug-in or if it may be due to the plug-in being El Cap compatible.

Hey Sharon,

These plugins have been updated on November 3rd, which means they will probably also have been modified for the new AU validation process in El Capitan. It is pretty much possible that this may cause your validation issues with Yosemite now. Why iZotope has not mentioned this earlier is beyond me. I would suggest taking this up with them, using their support link: support.izotope.com

- Ronny

There are still reports of crashing on stabilization with some nVidia graphics cards. Seems to effect 2013 iMacs and maybe others.

The title crashing may well be corrupt fonts. Saw a number of reports of font issues after upgrading the OS.

FYI I stared using RX5 of the first time in Yosemite, and I'm getting consistent crashes with the Declicker in FCPX. Everybody has a few kinks to work out.

Thanks for your input, Tom.

That's the first thing we thought as well. But the user confirmed that he had repaired permissions, checked corrupt fonts, deleted preferences, ran just text with no video and tried with a new library before sending his report. I am still waiting for his test with the new admin account to see if this could be related to user directory issues.

- Ronny

Hey T,

Thanks for the warning.

I have RX5 Advanced running on my 5K iMac test machine with EC and I don't see any issues. I still use RX4 Advanced on the production systems running Yosemite. This runs fine as it always has, so there is no way I will be updating anything in production any time soon. We are not out of the woods yet with iZotope.

- Ronny

ronny courtens wrote: Thanks for the warning.

I have RX5 Advanced running on my 5K iMac test machine with EC and I don't see any issues.

I've had RX5 for a couple of weeks and besides testing the is the first time I've used it on a project. I could well be related so something else:

PlugIn Path: /Library/Audio/Plug-Ins/Components/iZRX5DeclickerAUHook.component/Contents/Resources/iZRX5Declicker.bundle/Contents/MacOS/iZRX5Declicker
PlugIn Identifier: com.izotope.audioplugins.RX5Declicker
PlugIn Version: 5.0.0 (5.0.0b135)


I struggle with the long term consequence of using 3rd party plugins (especially audio) with FCPX since right now we don't have an easy way of determining what is needed for what projects. I try to "bake in" as much audio changes as I can so that I'm not relying on a specific version of a plugin that might or might not work in a current OS.

I try to "bake in" as much audio changes as I can so that I'm not relying on a specific version of a plugin that might or might not work in a current OS.

Entirely agree. As a matter of fact I experienced something in this line today.

A client called that he urgently needed a new packshot on a tv-commercial. I had the project on an external Thunderbolt, so I said: I will quickly do this myself on our test system, which has EC installed. No problem, the new packshot was added in a wink. But fortunately I checked everything before sending the new file to the station.

The test system has iZotope RX5 installed, while the project was edited on our production machines that use RX4. None of the audio sweetening we had done with RX4 was carried over to the new system with RX5. So I had to bring the project back to a production machine using RX4 to do the export. I hope this is only due to the fact that these plugins don't officially work with El Capitan, otherwise I will never be able to update our iZotope plugins anymore because we have too many old projects using them.

- Ronny

MsJustine wrote: Why did Apple allow plug ins to crash FCPX?

Ideally this should not happen and the plugin architecture should prevent it. The old way of doing plugins -- not just with FCP X but any extendible app -- was to load the extensions into the address space of the main process. These would run as separate threads.

Since any thread within a process written in unmanaged code like C has full access within that process address space, a single error in any thread could bring down the whole process. This was very obvious in early Internet browsers which started a new in-process thread for each tab. An error within the code path of any tab would bring down the entire browser.

This type of design is more expedient from a programming standpoint since it makes inter-thread communication easy, plus the communications performance is high. The old viewpoint was plugin/extension behavior would be managed through code validation and testing. Unfortunately this does not always work -- you can't test everything perfectly, plus someone has to be responsible for all that testing.

Now the standard procedure for internet browsers is run each tab in a separate process, so potential damage is confined to that one tab. Interprocess communication is slower and requires more work than inter-thread communication, but this is necessary.

It appears that each 3rd party FCP X plugin runs within its own address space. I can see various plugin processes start up whether I use those plugins or not. Therefore in theory a crashing or misbehaving plugin should not crash the FCP X process.

Nonetheless there must be some type of interprocess communication and shared data. Ideally the host process should validate any data, pointers, etc passed from the auxiliary plugin processes. If there is an oversight or deficiency in the validation and at the same time the plugin passes some junk data it could cause the host process (FCP X in this case) to crash.

Really? Apple has to babysit third party developers? What universe to you live in? Seriously? Name me one os/app developer who does that. Just one.

I see it like this, take the industry we all use day to day, automotive, you can buy approved or unapproved parts. The unapproved parts are cheaper, but at very high risk, with approved parts, you know that the car manufacturer has checked, does from time to time recheck parts to ensure they conform to the standards as laid down, this ensures your safety as a car owner/driver.

The same should and I would have expected from Apple, if plug ins are a part of the software, that this code generated outside of the control of Apple is safe, virus free for example, and will not adversely affect the end product, FCPX.

Apple is expanding, so this means more staff, the salary of a few people in the quality control aspect would not be a bad investment, Apple can afford this. I am sure not every line of code is checked, maybe it is, I don't know.

It is not baby-sitting, if you know anything about baby-sitting, it is this, you as the baby sitter, do all the work, for worse than slave wages, the baby does not care.

Plug in developers are not babies, they run a business with the sole aim of profit, Apple encourages this, and I am glad Apple do, but I am sure Apple tries not to be reckless.

Android is an example of reckless out of control ideology, just this week I read 20 000 apps with virus/malware that is impossible to remove... Do we want this from Apple, do we want FCPX to be a huge trojan horse???

Who knows, maybe Adobe is a trojan horse, I mean having all your work open to the elements, via the cloud...is that safe??

MsJustine wrote: I see it like this, take the industry we all use day to day, automotive, you can buy approved or unapproved parts. The unapproved parts are cheaper, but at very high risk, with approved parts, you know that the car manufacturer has checked, does from time to time recheck parts to ensure they conform to the standards as laid down, this ensures your safety as a car owner/driver.

The same should and I would have expected from Apple, if plug ins are a part of the software, that this code generated outside of the control of Apple is safe, virus free for example, and will not adversely affect the end product, FCPX.

Sorry, but that is a weak and flawed analogy.

When an automobile manufacturer offers 'approved' branded parts, those parts are commissioned by the car maker. Indeed they should be built to precise standards the OEM require.

Conversely, plugins are purely the creation of a third party and are not commissioned by Apple. These plugins are the result of the free enterprise system where industrious developers seek to fill niche solutions with small tools that enhance a larger objective.

While Apple offers a pathway for additional functionality and capabilities to be added to their own software creations via an SDK ... Apple does NOT commission the creation of those plugins and has no responsibility for the content of those plugins or how soon or how well the third party developers prepare their updates for plugins created by third parties.

Apple has made their intentions known and even offered assistance by furnishing developers the SDK's, API's and beta versions of El Capitan since as far back as early June 2015. Is there another OS creator or hardware manufacturer that offers anything remotely equal to WWDC?

Apple has also had a solid history of working with developers, large and small to work on wide ranging issues and problems at no additional cost to the third party developers. Apple also goes to great lengths of requiring developers who market and sell there wares via the Apple app stores to meet certain criteria for compatibility and security.

I think Apple has done and continues to perform their due diligence. To believe otherwise is to completely ignore the evidence that recent history offers.

Whenever there are major advancements in operating systems, there are going to be some growing pains. These relative minor issues concerning FCP X 10.2.2 and El Capitan 10.11.x do not merit such concern. This issues will be remedied shortly and are not indicative of a larger concern.

I repeat my previous assertion ... your concerns are purely a tempest in a teapot.

At least wait until YOU have installed El Capitan to proclaim it a flawed situation.

P.S. ... Mentioning the total free-for-all that is Android in the same topic as Apple OS X is a purely obnoxious and ludicrous comparison.

ronny courtens wrote: I just got an e-mail from a user who has issues with titles crashing 10.2.2 since he updated to El Capitan.

I've been seeing lots of crashes using titles in pretty much every version of FCPX and on multiple OS's. In fact, that's pretty much the only time I see crashes, using titles.

Titles??? Who's titles? Apple 3d or plug in based titles???
Not going to say anything more.... :whistle: