I’ve got a user who is having trouble getting an Audio Unit to load consistently in Logic 10.4.6 (running on macOS 10.14).
He says it loads sometimes in a new/blank Logic session, but when opening an older session that he has added the plug-in to, he gets error dialogs, usually the “Failed to load Audio Unit…” one. Once it throws that error, he needs to re-launch Logic to get the plug-in to load in any session.
So I asked him to open Logic’s Plug-In Manager window, and rescan the plug-in. He sent me the log of the auval scan, and it succeeds… but then the log file ends with the line:
updating properties of AU Cheeseverb by reFuse Software…FAILED!
Googling for this sort of message produces low quality results. Can anyone here shed some light on what “properties” Logic is trying to update? Is there some mysterious Logic caveat I need to watch out for here?
For the record, that line does not appear in an auval scan done on a plug-in from the command line, so it’s not coming from auval itself but from Logic.
Also for the record, I have not been able to reproduce this bug once myself, even using the same “problem” session file as the user.
To wit, “Properties are typically non-time-varying, not directly settable by the user, and changeable only before an audio unit is initialized.”
Well, great, but that doesn’t tell me how Logic is failing when it’s updating properties, nor which particular property might be tripping it up. Maybe a debugger would shed some light on it, but as mentioned, I can’t reproduce this bug on my own system, so that option seems out of reach.
Well, good to hear I’m not alone in this. So far for me it’s only a couple users reporting this issue (and for one of them, it went away after a plug-in reinstall and system reboot).
I’m curious if you are testing your builds with pluginval. I am, and my AU builds are passing all pluginval tests at the highest level. So, no clues there for me – but if you are seeing “tons of people” with this problem, maybe pluginval would reveal an issue to you.
Isn’t pluginval for VST only? All tests there have always passed for me on the VST version of my plugins anyway.
Edit: Okay, I tried pluginval, it does work with AU! Nice. It passes all tests on my machine.
The AU version seems to be the problematic one. Do you know if AUv3 is more reliable? I have not tested that yet, actually.
In Logic, I can “validate” the plugin in the plugin manager (which uses auval I believe), and for me, it validates everything perfectly. On another customer’s (slightly older) Mac/Logic, it gives errors like in the first post.
I don’t have an older Mac or an older version of Logic to test either
Oh, it’s worth noting that it works fine for some customer’s regardless of the validation failing - they just have to manually check to “use” the plugin, and then it works. But this is not the case for everyone, it seems.
Perhaps it is a permission issue with the plug-in bundle? If it’s failing to update the plug-in’s properties, maybe that means it is unable to write to the plug-in? Under Get Info, un-lock the plug-in, and set Read/Write for all the types (system, group (i.e., admin) and everyone). I’ve read that that worked for someone reporting the same error with AUs.
I thought of something like that, but then figured there was no way it would try to write to the plug-in bundle… that would break any kind of digital signature, right? I figured Logic meant that it was updating its own copy of the properties list, in a cache file of some kind.
However, since the plug-in scan behavior from Logic isn’t documented anywhere I can find, I can’t rule it out that it’s not trying to write something back to the plug-in bundle.
My current guess is that Logic is having an issue with something in Info.plist. That would explain auval verifying the binary, but there still being something about the plug-in’s configuration that Logic doesn’t like. If I could replicate the problem here I could iteratively tweak the values, but it’s harder to do that when you’re asking a paying customer to try loading new versions over and over…
As a test, you could try replicating the issue by setting the bundle’s permissions to Read Only on your own machine(s). Just a thought. I wouldn’t think it was writing to the bundle, either, but I saw a post saying that fixed it for them.