"Updating properties of AU...FAILED!" message from Logic

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.

1 Like

I poked around a bit more in Apple documentation, and found their description of Audio Unit Properties here:

https://developer.apple.com/documentation/audiounit/audio_unit_properties?language=objc

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.

I have the same issue. Tons of people with older versions of Logic having this exact issue. It works fine on my Mac though.

Edit: Actually, 10.4.6 isn’t even that old, nor is MacOS 10.14. Nevertheless, lots of people are having this issue on my end.

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 :frowning:

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.

Had a report of my plugin working fine on MacOS 10.13.5 and Logic 10.4.1, so I’m starting to doubt that the problem is due to older software, and more something else like system configuration.

Eager to find out what’s going on now.

I’m still trying to figure out this issue.

Logic’s “Plug-in Manager” window does indeed make use of auval. But it’s the part of the Logic scan log after auval is done that is the trouble here:

> --------------------------------------------------
> AU VALIDATION SUCCEEDED.
> --------------------------------------------------
> 
> validation result: successfully validated
> 
> updating properties of AU Cheeseverb by reFuse Software…FAILED!

I cannot find an explanation anywhere of what properties would be “updated” at that point - what is being read by Logic, and where in turn it would be writing that information.

Rather frustating that Apple’s own auval tool validates the plug-in as compliant with Apple’s own plug-in format, but then Apple’s own flagship DAW still has some kind of undefined issue with it.

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.

Hey Howard, I appreciate the idea.

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.

I take it back. It was their Logic Pro.app that had the wrong permissions, not the plug-in(s).