AudioPluginHost does not recognize VST3 plugins with FFTW library

Hello,
On Windows 10, in AudioPluginHost I can’t run the plugins which have used the FFTW library.
AudioPluginHost just says “No compatible plug-in format exists for thos plug-in”.
At the moment I can’t test it in other hosts. But I am pretty sure it’s something wrong with my FFTW library configuration. It is very tricky to install it and use - yesterday I spend half day to install it on OSX and Win.

The plugin can be compiled without any issue so it seems like library is included properly. But the host does not recognize it.

When I have only included "fftw3.h", and variables declarartion like fftw_complex or fftw_plan then everything works perfect. And there are no problems.

The problems happen as soon as I use things like fftw_destroy_plan(), fftw_malloc() or fftw_plan_dft_r2c_1d().

I tried to put break points on lines with those functions, but Visual Studio don’t even go to those points.

There is not such problem on OSX AudioPluginHost.

I suppose I 've done something wrong on Windows, but have no idea what until I get no errors from intelicense.

Had any one of you such problems before?

For any help great thanks in advance.

Best Regards

Do you link to a static or dynamic linked FFTW library? In case of a dynamic one, this sounds like a runtime linker error…

Hah… that’s the problem because I don’t know.
I want to have it static to be build in my output *.vst3 binary. But don’t know how to do that.
I feel stupid, but I really still not sure how to link static library in VS (or rather to say in Projucer because I always open project from Projucer). There are planty tutorials how to do that but all of them are not clear to me.

But still if it is linker error then wouldn’t it be shown in Visual when compiling? I’ve seen such errors hundreds times, but now there is not any issue shown in VS output window.

Okay, let’s start step by step :slight_smile:

When adding external libraries to your project, there are a few generally different approaches.

You can compile the libraries code along with your project code. This means that you need access to the headers and the implementation (.c/.cpp files) and compile the source files the same way you compile your projects files. In many cases, libraries need some specific build settings that might clash with your projects build settings or they simply consist of a lot of files, so it’s better to compile them separately or directly obtain a precompiled version of the library and its corresponding headers.

While the code compiled along with your project will always become a part of your binary, this is not always the case for pre compiled libraries.

A static linked library will become a part of your binary. Those libraries have a .a file extension on macOS/Linux and a .lib file extension on Windows. This means, after linking to them at compile time, you don’t need them anymore.

A dynamically linked library won’t become a part of your binary. Those libraries have a .dylib file extension on macOS, .so on Linux and .dll on Windows. You need them during compile time and during runtime. So, if they were available at a known location during compile time, the linker will be able to find them in this step. But the linker is not only used while compiling, it will kick in again every time you try to open the application that uses a dynamic library, and will look where to find that dynamic library since the executable parts of your library are not present in your application or plugins binary. If this fails, you usually get some hard crashes instead of more or less understandable linker errors you see if the linker does not find some function at compile time.

All operating systems have their own convention regarding where the runtime linker will look for libraries at runtime. And you have to make sure that your plugin installer will place your dynamic library dependencies in a suitable location on your system in order to make the plugin run. Since this can be a bit challenging to get right, most plugin developers chose statically linked libraries.

I hope this helped you understand the basics a bit better. So now, do you link your Windows build against a .lib (static) or a .dll (dynamic) version of FFTW? You must have chosen at least one of them in order to complete compilation successfully.

Wow… man great thanks for your support.

But to the point. I linked only the libfftw3-3.lib file. So as you told it is static and it should be compiled and linked statically to my binary. So it still doesn’t solve my problem.
It looks like it is linked in proper way due to fact the compilation goes with no problem.
Maybe the *.lib file is not enaugh and there should be set some special Flag to tell VS to link statically to the binary. There are some flags I set on OSX, but on VS I only set directories like in properties:

  1. C++ → Additional Include Directories
  2. Librarian → Additional Dependencies
  3. Librarian → Additional Library Directories
    And that’s all.
    (By the way I still don’t know how to set it in the Projucer project to not being forced to define it again and again when I open my project in VS from Projucer).

Maybe I should also set some flags like I set it in Projucer for OSX in the “Extra Linker Flags” I set that:
-L/usr/local/lib
-lfftw3

But don’t know what to set for VS. I’ve tried the same, but it didn’t help.

But from the other side if it’s not linked statically to the binary, then why on debuging time I also get no error in VS, I just can’t load my plugin and get error only from AudioPluginHost.

Most likely that static library is an import library doing just dll import for you, not a version of the dll. Check the file sizes.

I don’t think that you can’t statically link fttw without compiling yourself. Do they provide static versions of the library?

And last, the license of fttw doesn’t allow statically linking unless your code is GPL (or at least OSS) or you pay 12500$ for a closed source license. It doesn’t seem to me that your code is OSS.

Do they provide static versions of the library?

I told that I link *.lib file (exactly libfftw3-3.lib) so as PluginPenguin told it’s static library.



But there is one more worth to mention think.
When I install the FFTW on OSX by:
./configure
make
make install

It takes really long to built, and many informations appear on console screen.
While on Windows to install I used Visual Code Developer Command Prompt with command:
lib /machine:x64 /def:libfftw3-3.def

And it takes almost nothing. Just rapidly after “enter” hit everything is done.
So it’s strange that on OSX it looks like it’s complicated process while on Windows it is not.
Maybe the problem has somethind to do with that fact?


And last, the license of fttw doesn’t allow statically linking

Even in home for personal usage to testing purposes? It looks like I need to read license more carefully.