Problem using LimeLM with TurboActivate

Hi,

We are currently trying to use LimeLM with TurboActivate in our newest product and we’re facing problems with the implementation.

We got the standalone version working fine, but we have troubles with the VST3 and AU.

The plugin builds fine, but the DAWs refuse to open it (Studio One, Logic Pro, Reaper)

Studio One just doesn’t load it, without any message or pop-up.

In Logic, the plugin fails auval with: ‘FATAL ERROR: OpenAComponent: result: -1,0xFFFFFFFF’.

Reaper tries to load it, but fails with: ‘The following effect plugin could not be loaded:’.

PluginVal with VST3:
“!!! Test 1 failed: Expected value: , Actual value: Unable to load VST-3 plug-in file
!!! Test 2 failed: Unable to create AudioPluginInstance”

PluginVal with AU:
“Num types found: 0
!!! Test 1 failed: No types found”

It fails all the same even if we don’t actually use LimeLM in code, just including the library seems to mess with the plugin.

We’re testing it on macOS (non-M1, 2 different machines), following the LimeLM Tutorials on their site:
‘Using TurboActivate with C, C++, & ObjC’ and the ‘… on macOS’ section.
Including the .dat and the .dylib files inside the ‘contents/macos’ folder (as per the ‘… on macOS’ tutorial) doesn’t help.

Any ideas what we could be doing wrong?
We’ve seen @midiculous and @tsenkov mention LimeLM here, maybe you guys know a solution?

It sounds like you are using the dynamic library version of TurboActivate. It’s likely that the plugin is failing to load because it’s unable to resolve the dependency on this dynamic library. I’d recommend switching to a static library version, if possible.

yes, the problem is with the plugin unable to find the dynamic library. You need to include it in a subfolder within the plugin (but you need to sign it beforehand) and add the following in the Custom XCode flags in the Projucer:

LD_RUNPATH_SEARCH_PATHS=@loader_path/…/lib

It’s better to use the dynamic version, as it’s way more up to date than the static one.

Thanks @reuk and @swar.
We found the solution.
It was caused by linking to the dynamic library using “@executable_path”.

As mentioned in that post (and just like you said, @swar):

it turns out that for plugins, “@executable_path” points to the Host’s binary.
To point to the plugin’s binary, we needed to use “@loader_path” instead.

So, using “@executable_path” for Standalone version and “@loader_path” for the Plugins, everything now works.