Generated .dll and .vst3 not detected by DAW (Reaper)

Hi there !

I want to share the VST in .dll and .vst3 to friends but when I send them the file, their DAW (Reaper) cannot find the file. Among them, there’s one who also codes and compiles his VSTs very well, but his DAW doesn’t seem to want to detect the ones I send him either.
(While writing these lines, I realize that we haven’t tried to play his VST on my DAW, so I don’t know if the reverse is true for my friend)

While searching on Google, I saw that other people had this problem and a solution was to install a C++ program. For my part, I don’t remember having installed a particular program to detect VSTs generated with Juce and VS Code, after it’s been some time since I started so I don’t have too much confidence in my memory ! :laughing:

Can the problem be solved on my side during the compilation or is it up to VST users to install an X program in C++ on their computer ?

Gabriel

Are you on the same platform (Windows, macOS e.t.c.)? Otherwise that’s the problem.
Perhaps also the possibility is that one of you run/compile in 32 bit and the other in 64?

I seem to recall some specific issues with .dll also requiring some extras on the system but I only compile vst3 on Windows so I’m not sure.

There are the following things to consider :

  • A plugin built on Windows won’t work on Mac Os and vice versa
  • The 32/64 bit CPU architecture must match (if you build an x64 plugin, the user must use a 64 bit host in a 64 bit OS)
  • You should distribute plugins as release builds, not debug ones
  • On Windows, the appropriate C++ runtime may be missing on the user’s system. This is most easily fixed by statically linking the C++ runtime into the plugin.
1 Like

Is this valid for vst3 also?

Yes, it’s the same for VST3. For some reason, the default setting in the Projucer is to use the dll-based C++ runtime instead of the static runtime which can cause the issue that the plugin won’t run on the end user’s system.

Great thanks. I read that a downside is that the runtime cannot be updated (of course), but I guess a new compile on a newly updated Windows system compiles with the latest runtime? So distributing an updated binary = updated runtime?

What could otherwise be the consequences?

Thank you ! It’s clearer now !

The VST appeared in the DAW ! (following all the points mentioned)

When trying to open the release version from the second PC, Reaper crashed (however this is not the case from the PC which generates it).

On your image, we see VST Binary Location with the path C:\VSTPlugins_64bit.
So we put a path.

By compiling, we have the file that is generated in the …\x64\Release\VST3 but we got an error.
The copy is not done as expected in the path of the VST Binary Location.


“The Copy command … it stopped with code 1”

Is this error causing Reaper to crash on the second PC ?
How can we fix this error ?

You need admin privileges. Run Visual Studio as an Administrator i.e., Windows Logo > Right-click Visual Studio 20xx > “Run as administrator”

The path in the screenshot is for the VST2 (“legacy”) plugin. VST3 plugins have a different designated path on the system that should always be used. Also, your target path seems to be for 32 bit (x86), which doesn’t make sense if you are doing a 64 bit build of the plugin.

1 Like

That’s not a good idea. It would be better to change just the permissions for the folder where the plugin is going to be copied.

1 Like

ah, good to know, thanks. Just changed the VST3 folder’s permissions for “Users” to full access, and copying works fine from VS.

1 Like

After changing the Path, the error disappears and the VST 3 copies well in the desired folder. Must have been the permissions issue !

By using the Windose Local Debugger in Realese
Release

and then placing the VST in C:\Program Files\Common Files\VST3 on the 2nd PC, we always have Reaper crashing with its configurations.

In the properties of Solution ‘NewProject’ on VS code the configurations are like this

In the jucer Release, that’s how it is


Is the configuration above correct?
What do you think I should check in the Jucer and VS code?

Does your plugin depend on something extra besides the plugin itself in order to function? Like some data or image file in some particular location?

I use XML files :slight_smile:

Well, in that case the Xml files have to be on the system where you are trying to test the plugin…Or you have to do some error handling in the plugin in case the files are missing.

I see !
Is there a solution to include the content of XML files to only have to transfer the VST?