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. Going by separate topics:
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. 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. XPC processes are by design supposed to be resilient to sudden termination, but FxPlug 4 doesn’t take this in consideration. 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. 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. 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. From our experience, there are never actual crashes behind this symptom. 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.
As 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. 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. 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. 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.
If there is only one thing you take away from this, is that you (and your users) should file feedback through this page:
Unless Apple is made to understand how many people are affected by this problem, they have zero incentive to look into it. Nor should we blame them for not improving a situation they may not be aware of.
We (plugin developers) should clearly talk about this issue amongst ourselves and following this post I will be in touch with Vuo’s developers. That’s it for the FxPlug 4 issue…
@kingluma also mentions us (FxFactory, FxCore) and me specifically, and I think it’s important you hear my side of the story. He had indeed developed a product that relied on other software to implement functionality that wasn’t otherwise available in Quartz Composer. His explanation would give the impression that our rejection was unjustified, given the fact that the software in question had a permissive license and that since all of Quartz Composer is on the endangered species list, why would we be prejudiced against something that taps into that ecosystem? The risk for such a product would be no more no less than for the technology as a whole.
If you have been with us for a while, you probably know that we have shipped (and continue to ship) all manner of third-party software, some based on “fourth-party” components used under license. So why would Dirk’s situation be any different? Let me try and condense the discussion in a few important points.
-
The software in question was not based on the official Quartz Composer plug-in SDK. It was a fun, useful hack based on a long-living backdoor, a known secret that made Quartz Composer so attractive to early users and hackers in general. This in itself should be an astounding discovery for most developers who think they know how Apple operates. Yes, once upon a time there was(is!) a system level framework that strangely supported a secondary, undisclosed plug-in mechanism in addition to the official API. As Apple reviewed every framework in macOS, tying up all loose ends… this particular corner was left with this massive unexplained hole. My best guess as to why it played this way: not enough people at Apple may have even known about this, or considered it no more no less dangerous than the Obj-C runtime itself, and OpenGL/CL/QC were destined for the scrap yard anyway, so why bother fixing/improving technology that is already on the chopping block?
-
Shipping production software based on unofficial SDKs should strike everyone as a bad idea, but even ignoring that… was our fear of potential problems unjustified? In other words, when so many wonderful hacks were available through this unofficial SDK, and Apple seemed happy looking the other way, was I being unreasonable or overly cautious?
As it turns out our actions were not based on hypothetical, overly pessimistic scenarios. Years before Dirk started working with FxFactory, we actually did ship products based precisely on a set of Kineme patches. Surprised? Don’t be. The duo behind those patches was extremely talented! One made Vuo a reality ;-) The other helped us with some products, then landed a job at Apple and is probably/hopefully still doing some amazing work on the OS team. Clearly our rejection was not about lack of faith in the authors, but on actual history. At some point in the macOS timeline before Quartz Composer was discontinued, Apple made changes to the technology that broke many plugins based on the unsupported/unofficial SDK. The end result was that a bunch of products stopped working. It got worse: because plugins based on the unofficial SDK hacked into the QC infrastructure their code ended up breaking other QC-based products, even those that did not make any use of custom hacks (and I use the word hack in a good way, the only way®). We were in a situation where all developers in an ecosystem have to pay the price for the unwise decisions made by one. I ended up having to build diagnostic tools inside FxFactory to detect the presence of these outdated, unofficial plugins just so that users would know how to update them, rather than blame us for “not being on top of macOS updates”.
It took only weeks for this problem to be solved, but lots of unhappy users sending emails we had to respond to. Let’s not be naive: these scenarios happen all the time, and they don’t just happen when you use unofficial SDKs or hacks. But there is an important difference: if you discover a bug or a regression in a supported API, you can expect to get Apple engineers involved through the feedback/bug reporting process. When you’re dealing with unofficial APIs your chances are basically zero. It’s one thing to say the foundations to your software can fail, it’s another to willfully pick poor foundations to begin with.
So if anyone walks up to me and asks:
- I want to ship software based on an unofficial SDK to a (by then) dying graphics technology
- I did not actually write this software
- I would not be able to address any issues myself, reasonably speaking, without hiring someone for the job
…then please don’t hold it against me if I politely refuse, again. I’m here to help you understand my point of view, I will guide you to better solutions, but I cannot willfully make the same bad decisions again.
Dirk’s comments bring up another interesting difference that comes up often in our interactions with developers. Over the years the Kineme patches were at the heart of a couple fiascos for our software, but they are not the only proprietary or third-party code that ever put us in that situation (heck Quartz Composer itself is now a liability). There have been other situations where developers put together effects based on some custom or off-the-shelf component, shipped it, and then left us to maintain any future mess. There is a wrong assumption I often see being made:
“If something worked yesterday, and broke today, it is because Apple/FxFactory/Leprechauns decided to make (unnecessary!) changes that broke my software. While I knew I would need to update my software, this does not fall into the implied responsibilities I felt. It should be Apple/FxFactory/Leprechauns who need to fix this mess.”
To me, the obvious problem with this attitude is that it’s trying to assign blame for something that is actually pre-announced, inevitable and natural. It is the very nature of software to live in an environment whose variables are complex and constantly changing. All too often I see a preference for “following one’s own instinct” over accepting decent advice from those who’ve been in that exact spot for a while. The problem of trivializing the unknowns to favor a gut opinion seems to be a peculiar trait of the software industry… I doubt many would apply this same “follow my instincts” when bringing a car to a mechanic or getting help from a doctor for a Cancer diagnosis.
So… the fact that macOS, Final Cut Pro, etc receive regular updates should not surprise anyone. Whether the blame is in your code or not, what matters the most to your customers and your bottom line is whether you have a plan in place. And that plan should carefully consider what external software components you are using, whether you have someone ready to update them for you, and whether you are ready to bare those costs. If I had explained this in more detail to Dirk, perhaps he would have been less disappointed and we could have looked for alternative solutions.
everyone!
