VST3 Not Compiling Additional .cpp and .h files

Hi everyone,

I posted here a week or so ago about my amp sim sounding great in the standalone app, but awful in a DAW (using the exported VST3).

I thought it was a code mishap, but further testing has revealed that only the processes initiated in the main pluginprocessor.cpp and .h files are taking any effect, which is strange considering external file processes like filtering and waveshaping work in the standalone.

Has anyone encountered this before?? I have no idea how to get the additional waveshaper.cpp/.h and pre/postEQ.cpp/h files to compile into the VST3 and its driving me nuts!!

Any help would be greatly appreciated. Thanks.

1 Like

Have you made sure that those files are selected for inclusion in the VST3 plugin target? There’s a difference between Standalone App and VST3 configurations, and it sounds like you’re not including the files you expect in the VST3 plugin target.

But, then again, would your project compile without the files? If yes: why? That’s your real issue.

2 Likes

Hi,

Thanks for the reply.
How would I look into the VST3 configurations?

I ran a code analysis on the VST3 build and it seems like each file is compiling, but the output in the DAW says otherwise. Very strange.

Are you sure you’re not running an older version of the VST plugin? Did you force your system to rescan all available plugins and rebuild the plugin list?

Something I always run into, developing on MacOS, is the fact that there are multiple places on the system, where VST plugins can be located … and sometimes I don’t install the new version over the older version. Double-check that, because otherwise its pretty weird that you’re not getting compiler errors about missing files …

1 Like

Hi,

I’m using Ableton 11 on a Windows 11 laptop and each new VST3 build is pasted to overrite the previous version in the appropriate plugin folder, which I then rescan before opening the plugin in the DAW.

I’ve ran Visual Studios analysis tool on the VST3 and it does say that each .h/.cpp is included, so I have no idea what’s up here.

At this point I might just remove the additional header files and just instantiate everything in the main pluginprocessor files.

Hi,
Just to make sure, did you add the additional files in your Projucer project? It’s necessary for an effective wrap of all the .cpp and .h files.
If not, try creating/adding new .cpp/.h files as needed, save the project and open it on the IDE you’re using.

I hope it’s that easy!! Let us know.

Giacomo

1 Like

Hi,

Yep I’ve added all the relevant source files in Projucer (into the source folder) and have selected all to compile, which checks out seeing as the Standalone compiles properly and produces a good result.

I still have no idea why the VST3 isn’t including all the source files, I’m sure its a matter of checking a box in Visual Studios options but I don’t know where to look.

Are you testing both in debug and release mode? Are you getting the same results?

Aside from including the header files, how are you making them interact with each other? Are you calling the right prepareToPlay() and processBlock() methods?

1 Like

I’ve just been following JUCEs tutorials and creating the neccessary functions (process() and prepare()) for each component in their .h/.cpp files before initiating them in the pluginprocessor files as a chain.

When I build the standalone app it works as expected and sounds great, but the built VST3 sounds awful in Ableton, as if its missing parts of the chain.

I’ve tried release mode once before but I’ll give it another go.

Tried a release version, same exact issue. Man this is irritating.

I might try building each component as its own plugin and seeing if there’s a specific process responsible but its unlikely.

1 Like

Did you debug the plugin? To me this sounds like some error in your processing code that is triggered under certain circumstances when running as a plugin but not when running as a standalone. Typical problems could be an unexpected block size being passed to your processBlock callback, a different order or number of calls to functions like prepareToPlay and processBlock etc.

Attaching a debugger and stepping through the prepare and process functions in order to get an idea what’s going on in your code at runtime is typically the first thing to do when you are facing problems like that.

2 Likes

Hi there, thanks for the suggestion

I attached it to Ableton and loaded the plugin, but there was no information being output anywhere?

Well, only attaching a debugger won’t help, you have to set breakpoints in your functions and then step through them in order to get some insight. Do you have any general experience working with the debugger?

2 Likes

Hi,

No I don’t have any experience, I just run a debug/release build and if it compiles without errors then I generally don’t ask questions, until now at least. I’ve been doing basic coding for a couple years for my audio tech degree but nothing as deep as my current project (not to say its anything special haha).

I’ll look into adding breakpoints, seems easy enough and should hopefully yield something I can use. Thanks for the patience, I know this is pretty basic.

I doubt any files are failing to be included in the build. That would cause compile or link errors when building, in places where the functions or objects in those other units are accessed/called. More likely, you’re just not calling those functions in certain cases. Find the code that calls into those functions/classes, and see if they are getting called at all by setting breakpoints there.