Plugins showing up twice on High Sierra OSX 10.13


#1

I have received some reports by High Sierra users that the plugins show up twice in the plugin list. This happens in Ableton Live and Logic X. Why does that happen and is there a fix for this?


#2

Me too. not sure about the cause, but updating the plugin with the last git develop version fixes it.


#3

Good to hear that it works at least with the develop. Still interested what the problem fixes.


#4

I found this issue too for some 4.x versions, but it seems to be OK on Juce 5.x and 4.3.1.


#5

Does anyone know what might have changed in develop that would affect this?

We’re getting some reports of plugins showing up twice and/or rescanning every time Logic X launches, but we can’t reproduce it on our own machines.


#6

I could not reproduce it either, but here is something I noticed that might help you test it indirectly.

Say your plugin version is 1.0.0. If you add you plugin.component in both Components directories :
/Library/Audio/Plug-Ins/Components/
and
/Users/YourUsername/Library/Audio/Plug-Ins/Components/

and then open the plugin manager window from logic you will see your plugin twice (that is normal).
But if you plugin is sensible to that “showing up twice and/or rescanning every time” bug, then you will see wrong versions numbers for those in that plugin manager window. Like instead of seeing 1.0.0, you will have 0.9.0 or something like that. at least that was like that for me.

When I updated to the last develop tip that fixed both that weird versions and the bug described above, so those are probably related to one another.


#7

Anyone figured out the cause of this yet? Also, does this only affect Juce-built plugins? I’ve seen a bunch of plugins in High Sierra with the double listing, but Juce is pretty popular. Popular enough that I’m wondering if Apple is going to fix this problem on their end in an auval/High Sierra update.


#8

We had this when there was a mismatch between version number in AU and plist.
Xcode do not reset very well plist when doing a new build with version number generated through processing, so try a clean build


#9

I hit a similar issue right yesterday: auval was failing with message

“ERROR: Component Version mismatch: Res Vers = 0x10102, Comp Vers = 0x10103”

In my case, I solved it by adding a pre-build script that does a

touch include_juce_audio_plugin_client_AU.r

inside the JuceLibraryCode folder.

Unfortunately, the Rez command (at least in Xcode 8, which I’m using), only reacts to the update of the file it is Rezzing, NOT of those that said file #includes, recursively.
This means that updating “AppConfig.h” with the new version number seems to be not enough, touching the main ‘.r’ file seemed to be the only viable choice


Version management vs. Projucer
#10

I don’t understand what’s going on.

I got this failure on a High Sierra install:
ERROR: Component Version mismatch: Res Vers = 0x10200, Comp Vers = 0x10300

But the same plugin passed on a (non) Sierra install.

I looked everywhere but I don’t see version 1.2 anywhere in my code or in the .r file…everything should be 1.3.

And why only High Sierra?


#11

Who here also has AUv3 enabled in their build? That could be a relevant factor…


#12

As I said in my post above, this may happen if you update the version number of your project by editing AppConfig.h directly.

When rebuilding the project with Xcode, the Compile phase will correctly pick up the updated version number (1.3.0) but the Rez phase will fail to do so because it only looks at the timestamp of the include_juce_audio_plugin_client_AU.r file contained in JuceLibraryCode, and will not check whether one of the files it recursively includes has been updated as well (which would be true for AppConfig.h in this case).

The net result is that in this circumstance Rez will not run, believing that there are no changes to the file it uses as “source”. This means that your binary will be produced using the “resouces” file that was created with the previous run of Rez, which probably embeds the old version number (1.2.0), which mismatches with the one compiled in code.

The message that you are getting from auval seems to indicate exactly this.

As for why you are only getting this in High Sierra, I don’t know, maybe they updated auval in High Sierra to include a new check that wasn’t performed in earlier macOS versions.

P. S. by no mean I intend with this post to encourage the usage of Projucer to maintain a JUCE project. In fact, it is my belief that a properly formed project should compile and run fine without external tools to “massage” it.


#13

I understand, but I never update the version number in AppConfig.h directly.

Also, it looks like auval is at version 1.6.1a1 on both High Sierra and Sierra.

Hmmm.

On the other hand, I did as you suggested and touched include_juce_audio_plugin_client_AU.r and then rebuilt my entire project and it installed and passed auval perfectly.

Thank you.


#14

I wonder if there’s a method in Xcode to auto-touch include_juce_audio_plugin_client_AU.r before compiling…

Rail


#15

Clean build is a good solution when you release a new version so you can be perfectly safe.


#16

You can have multiple “Run Script” phases at whatever point in your build process (see picture), so you can add one before compilation and write there the instructions to touch that file.

27