Problem using LimeLM with TurboActivate

[danwit777]

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?

[reuk]

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.

[swar]

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.

[danwit777]

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

Problems linking to .dylib

Oh okay, I found the solution by myself. In case of a plugin, @executable_path resolves to the DAWs executable. @loader_path resolves to the plugins path when its loaded inside a DAW. So I just switched the install name of the lib back to @rpath/mylib.dylib using: install_name_tool -id @rpath/mylib.dylib mylib.dylib And then I add two new rpaths to the resulting executable using: install_name_tool -add_rpath @executable_path/../Frameworks install_name_tool -add_rpath @loader_path/../Framewo…

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.

[jjburred]

Actually, @loader_path works as well for standalones, so you can just have a common setting for both plugin and standalone targets.

Any hints as to what is the best Windows way to do this? (specifying a custom runtime path for TurboActivate.dll for either the exe or the vst)