Plugin blacklisted by Nuendo, not found by Reaper


#1

Hey guys.

Our plugin works fine on most PCs (VST2 build) and Macs (AU build).

Recently, the PC in our demo-room was updated from Windows7 to 10. From that moment on, the Plugin stopped working on that PC.

  1. Plugin64.dll gets black-listed by Nuendo 8 and cannot be re-activated.
  2. Plugin64.dll does not get detected by Reaper, even after several re-scans and cache clears.
  3. Plugin32.dll gets detected in Reaper and works, but in bridged mode. Nuendo no longer supports 32-bit plugins so it doesn’t get detected there but I guess that is expected.

Like I said, the Plugin works fine on mine and other Windows10 PCs, so I don’t know why just this one computer has issues.

First I though this may be a windows permissions thing. However the account they are using has admin rights, which they used to install both DAWs, copy the plugin’s binaries, etc.

Looking around the forum I found this thread: Cubase 9 blacklists plugins
So I used the vst-scanner tool on our Plugin. The result wasn’t very helpful:

* vstscanner on Plugin32.dll
** No output (does that mean no errors, or that the tool didnt work?)

* vstscanner on Plugin64.dll
<pre><code class="xml">
C:\Users\...>vstscanner.exe -p Plugin64.dll
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
<path>Plugin64.dll</path>
<error>dll does not export the required &apos;GetPluginFactory&apos; function</error>
</plugin>
</code></pre>
** This seems a VST3-specific thing (GetPluginFactory). I guess vstscanner is meant for VST3 plugins, so not relevant for our plugin.

* vst2xscanner on Plugin32.dll
** No output (does that mean no errors, or that the tool didnt work?)

* vst2xscanner on on Plugin64.dll
<pre><code class="xml">
C:\Users\...>vst2xscanner.exe -p Plugin64.dll
<?xml version="1.0" encoding="UTF-8"?>
<vst2xplugin>
<path>Plugin64.dll</path>
<subCategory>Fx</subCategory>
<cid>...</cid>
<editorCid>...</editorCid>
<name>Plugin64</name>
<vendor>...</vendor>
<sdkVersion>VST 2.4</sdkVersion>
<vendorVersion>...</vendorVersion>
<latencySamples>0</latencySamples>
<canDoublePrecision>0</canDoublePrecision>
<audioInputBusCount>1</audioInputBusCount>
<audioOutputBusCount>1</audioOutputBusCount>
<mainAudioInputArr>3</mainAudioInputArr>
<mainAudioOutputArr>3</mainAudioOutputArr>
</vst2xplugin>
</code></pre>
** So... no errors, I guess?? 

Anyone have any ideas?


#2

Are you linking to the Microsoft C++ runtime library statically or dynamically? (If it’s the latter, maybe the system doesn’t have the library dll installed.)


#3

Up till now I always linked dynamically, as per default (see screenshot of my JUCE build config).

I just changed the Runtime Library setting to “Use static runtime” and sent the resulting VST binary to my colleage. Let’s see what she says.

With the static runtime I was unable to build as AAX, though.


#4

You’ll have to make sure the Runtime Library setting is the same when building the AAX SDK.

But in any case it’s better practice to use the dynamic runtime these days: IMPORTANT BREAKING CHANGE: JUCE will now use dynamic linking for the Windows runtime by default


#5

But then you have to start ensuring the end user machine has the separate runtime installed…Sigh.


#6

Yeah, it’s an obnoxious issue for sure :stuck_out_tongue: At least it’s not too difficult to bundle the redistributables into one’s product installer.