CMake plugin installalation issue (Mac)?

General JUCE discussion
1

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.

Thx

2

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
3

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

4

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
5

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).

thx

6

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?

2 Likes
7

interesting. i’ll check that out. thx

8

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