Problem loading plugin on FLStudio

Hi everyone, i have a problem with my plugin on FL Studio 20. I developped the plugin on my personal computer with juce and visual studio 2019 and it works fine, either on the plugin host than on FL Studio. But when i tried to use it on my other computer ( nothing installed on it except FL Studio) it seems that the plugin doesn’t work and FL show me this error :

And when i change the type value of the plugin to Effect it shows me this error :

Capture3

I made some research on it, and it leads to think that maybe the problem comes from the static/dynamic linking library but i tried both modes and it didn’t help much.

the plugin is installed in : C:\Program Files\Common Files\VST3
it is build as a 64 bit plugin
and both my computers are on 64 bits window.

Can someone helps me please? Thank you!

This would have been my first guess as well. How/where did you modify the runtime linkage options? Did you set it for both, debug and release builds to static linking? Did you try any other host besides FL studio on the other computer?

I have 3 configurations debug x64, debug win32 and release which is x64. I set the runtime linking to static linking directly in juce. I got a friend who tried it on cubase (windows) and an other one on logic pro ( mac) and they both have the same problem, the plugin doesn’t load.

Finaly it worked! it didn’t because i used the wrong build, sorry PluginPenguin for the misunderstanding :sweat_smile:. So the problem was that i needed the static linking library mode instead of the dynamic one. However how can i manage to use the dynamic linking on a computer that doesn’t have the needed libraries? Do i install them with the plugin in the ino setup installer or i tell the user to install them by himself? Which one do i need the user to install?

EDIT : I also have the same problem with macOS but it seems like there’s no way to setup static linking on it. Any ideas?

I think both are theoretically possible solutions but it won’t be very convenient to tell the user to execute a second installer in order to make your plugin work. But to be honest, I always went with static runtime linkage on Windows to avoid the whole topic and I’m currently facing the very same question myself, as I introduced a dependency to a third library that needs the dynamic linked runtime to my recent project. You’ll likely find a thread on that round here in a few minutes :wink:

So that being said, if you have no real need to use the dynamic linked runtime, just stick to the statically linked one and all is fine.

Regarding MacOS: There you don’t have to care about that. So I guess you must be facing some different problem here. On Mac you might face the problem of having chosen a relatively high deployment target and seeing the plugin fail loading in case your tester runs an older version of Mac OS, you can change that in the exporter settings as well.

If this is not the case, do you link against further third party libraries? Here of course static vs dynamic linkage is relevant