# Problem using LimeLM with TurboActivate **URL:** \ **Category:** Development\ **Created:** [January 19, 2022, 10:26am UTC](https://forum.juce.com/t/problem-using-limelm-with-turboactivate/49747 "2022-01-19T10:26:27Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![danwit777](https://avatars.discourse-cdn.com/v4/letter/d/ecb155/32.png) [@danwit777](https://forum.juce.com/u/danwit777)\ **Post date:** [January 19, 2022, 10:26am UTC](https://forum.juce.com/t/problem-using-limelm-with-turboactivate/49747/1 "2022-01-19T10:26:27Z")
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? ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [January 19, 2022, 12:10pm UTC](https://forum.juce.com/t/problem-using-limelm-with-turboactivate/49747/2 "2022-01-19T12:10:20Z")
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. ---
**Author:** ![swar](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/swar/32/12935_2.png) [@swar](https://forum.juce.com/u/swar)\ **Post date:** [January 19, 2022, 12:43pm UTC](https://forum.juce.com/t/problem-using-limelm-with-turboactivate/49747/3 "2022-01-19T12:43:54Z")
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. ---
**Author:** ![danwit777](https://avatars.discourse-cdn.com/v4/letter/d/ecb155/32.png) [@danwit777](https://forum.juce.com/u/danwit777)\ **Post date:** [January 20, 2022, 2:51pm UTC](https://forum.juce.com/t/problem-using-limelm-with-turboactivate/49747/4 "2022-01-20T14:51:06Z")
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](https://forum.juce.com/t/problems-linking-to-dylib/35675/2): > > 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. ---
**Author:** ![jjburred](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jjburred/32/15065_2.png) [@jjburred](https://forum.juce.com/u/jjburred)\ **Post date:** [February 16, 2023, 11:24am UTC](https://forum.juce.com/t/problem-using-limelm-with-turboactivate/49747/5 "2023-02-16T11:24:49Z")
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)