CMake plugin installalation issue (Mac)?

Hi, noticed this recently.

  1. Build a projucer plugin - scans fine and appears in Live
  2. Build a projucer plugin then build the same plugin in cmake - doesn’t appear in Live
  3. Build a projucer plugin, delete it, then build the same plugin in cmake - appears in Live

So, looks like CMake installing a plugin over an existing plugin built in Projucer is causing a problem - easy to resolve by removing the existing plugin in the cmake process, but looks like there might be an installation issue from CMake.


In case you are experiencing that with a VST3 plugin: I haven’t used the Projucer for a while, but I remember that it generated legacy non-bundle VST3 plugins. CMake generates the recommended bundle format, so it might be an issue overwriting a non-bundle plugin file with a bundle folder that causes this fail?

1 Like

Hi, this is on Mac so all of the formats are already bundles. thx

What does “the same plugin” mean in practice? Does the plugin share all of the same attributes in each build - manufacturer code, plugin code, name (identical spelling/spacing), version, preprocessor definitions, etc?

You also haven’t mentioned the format(s) you’re testing. On mac, the system can be a bit picky about when it registers new/changed AU plugins, so what you’re seeing may be entirely due to the system itself, especially if there are version or plugin-code differences between builds.

That was changed recently. The Projucer’s MSVC exporter now generates VST3 bundles:

1 Like

So, formats are AU, VST, VST3. I’m aware of the AU problems on Mac, but I’m primarily testing VST.

I think in this case the fact that if a plugin is created by projucer it works, it it’s created by cmake it works, if it’s created by Projucer and the CMake version copied over it, then it doesn’t work - that suggests a problem with that part of the process?

As for the rest, I guess that’s the question - what does a DAW use to determine the plugin is the same (I’ve raised another issue about this).


Maybe it’s related to signing. I think CMake will avoid copying/installing some of the bundle contents if their timestamps are older than the timestamps of the installed files. I guess there’s a chance this could break the bundle signature.

Have you checked that the signature of the installed bundle is valid after overwriting the bundle from a CMake-generated build?


interesting. i’ll check that out. thx

Definitely seems to be related to this as if I resign the plugin after installation by CMake then it’s all good.

At the end of the day, I have 2 solutions now, so can proceed. thx