New PSP PianoVerb Installer installs Intel Only AU by mistake RESOLVED

[James Steele]

Just a heads up on the off chance this helps someone. PSP posted and updated version 1.10.2 of PianoVerb recently. Main improvement was ARM support for AAX. Only downside is somebody there goofed and the previous version 1.10.1 of the Audio Unit gets overwritten by a version 1.10.2 that is INTEL ONLY. Verified this just now not only with PlugInfo app, but also instantiating it in a project and verifying that it triggers AUCompatibilityHostingService process in Activity Meter.

I wrote to PSP about this. In the meantime, I updated VST3 and AAX to 1.01.2 and then used Time Machine to restore version 1.10.1 of the Audio Unit.

[mhschmieder]

As I wrote to them about a similar issue with another update last month (I forget which one) and they were on it with an updated and corrected installer set the next day, I hope for your sake that the same happens for PianoVerb.

[James Steele]

As I wrote to them about a similar issue with another update last month (I forget which one) and they were on it with an updated and corrected installer set the next day, I hope for your sake that the same happens for PianoVerb.

Yep. I vaguely remember an issue, also. It was probably with Spring Box. If I reported something on that, I used their webform, so I have no copy in my outbox. It's not a big deal about PianoVerb. I actually don't use it much, but it was interesting to me that something like that could slip through the cracks. I imagine perhaps some box wasn't checked on a compiler or something? I wouldn't know.

I doublechecked that it was Intel only before I wrote to PSP, rather than trust PlugInfo... although that app has always been right in the past. I learned a trick from a user on Gearspace. Open an empty project in DP, create an audio track. Open up Activity Monitor in the background and sort the view by Process Name. Now add that plugin to the track. If the plugin requires Rosetta, you will see a process called "AUHostingCompatibilityService (Digital Performer)" start up. That's Apple's special implementation that lets us run AUs within our DAW without requiring the DAW itself to be launched in Rosetta.

The user over at Gearspace I referred to actually caught a bug where Native Instruments installers (this cropped up initially with Battery 4) was not fully overwriting the old Audio Unit. PlugInfo would show "Apple, Intel 64" (indicating Universal Binary 2) but it wasn't. He discovered this by instantiating the plug and seeing the AUHostingCompatibilityService process start up. The "fix" was to manually delete the old ".component" file in the Finder before running the installer. This happened with another NI plug as I recall. I think gradually they sorted this out. Part of the growing pains of Apple Silicon I guess.

[mhschmieder]

New update released today. I didn't read the notes so don't know if it is meant to address the platform issue.

[James Steele]

New update released today. I didn't read the notes so don't know if it is meant to address the platform issue.

I should have followed up. Antoni and PSP wrote me back and there is a new installer uploaded that fixed it.