Unfortunately this also explains why M1 users with 8GB of RAM are the most likely ones to be hit… a real shame because the hardware itself is wonderful: RAM can be flushed and repopulated orders of magnitude faster than most Intel systems… and so this should all just work with no discernible penalty. The more RAM on the system → the less likely macOS reaches the memory pressure threshold that starts this madness → the less likely you can trigger Final Cut Pro to display that alert and disable your plugin. Many developers are still on Intel systems, or bought M1s with 32GB of RAM or higher, which lessens the likelihood of reproducing the problem locally. If anything, it is more common to see Final Cut Pro crash… meaning that these low-memory situations appear to affect other portions of their code.Īs described (remember this is an educated guess) the problem is proving hard to reproduce, meaning that for some it is a dreaded guarantee, and others may rarely if ever encounter it. From our experience, there are never actual crashes behind this symptom. It does not matter if the code has an actual fault (leading to an honest-and-true crash) or whether the plugin played no role. Final Cut Pro appears to have its own threshold as to how it deals with these events: once the process hosting your plugin has quit enough times, it reports the plugin as non-responding. Final Cut Pro should ideally differentiate between planned termination and an actual crash, but instead seems to be interpreting all such events as failures on behalf of our code. XPC processes are by design supposed to be resilient to sudden termination, but FxPlug 4 doesn’t take this in consideration. My best guess is that when memory pressure reaches a certain threshold, macOS begins killing processes that host your FxPlug 4 plug-ins under the assumption that this can be done with no ill side effects. ![]() It is my understanding that all plug-ins running under the new FxPlug 4 specification are prone to seeing the “Plug-in not responding” error. Hi everyone! Was just made aware of this discussion and since I’ve been mentioned by name (what an honor!) there are a few things I can contribute to the discussion. I like and respect the FxFactory guys (I worked with Gabe at another company before he started FxFactory and I live an easy subway ride away from their office so I’ve visited them from time to time) but I’ll never forget the feeling of having a project that I had put in a lot of time working on be vetoed that way : ) That project also depended on FxFactory code (to make use of QC comps) so I wasn’t able to go forward with it - although now I could do it replacing the QC comps with Vuo comps etc. ![]() of course any FxFactory effects that make use of Quartz Composer at all are becoming difficult to maintain at this point… Anyway, I could be wrong but I expect that he might have the same attitude toward something that relied on Vuo. I think he didn’t want to have an FxFactory product that made use of any code that wasn’t his (or Apple’s) because he thought it would be difficult to maintain in the future etc. This product I had created relied on a free Kineme QC patch that was under an MIT license which explicitly allowed for it to be used that way (redistributed as part of a paid product and even modified etc.) but Gabe shut it down. Years ago I did a lot of work on something I intended to release for Final Cut Pro through FxFactory. I get the FxFactory marketing emails so I had actually seen the video already. Congratulations on launching the product - it looks useful.
0 Comments
Leave a Reply. |