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 kommentar(er)
