I've noticed that PVST doesn't detect a .vst3 (when scanning the shell) unless the file name of the dll is exactly the same as the stringPluginName specified in DEF_CLASS2.
other hosts don't care about this and i think it doesn't make much sense to enforce this?
VST3 DLL name
Re: VST3 DLL name
Odd, can you tell me which vst3 are not detected so i can test them?
Re: VST3 DLL name
Hm, I cannot reproduce this, I renamed a vst3, it still gets scanned and detected. I'll take a closer look what i'm doing with the stringPluginName in the shell.
Re: VST3 DLL name
Code: Select all
<Factory Path="C:\Program Files\Common Files\VST3\DDexed.vst3" Shell="0" Close="1">
<Plugin Name="Dexed" Vendor="Digital Suburban" Identifier="01EFCDAB8291EBFA4447534244657864" Synth="1" />

Re: VST3 DLL name
Ok, i managed to compile a test vst3 with the latest sdk, and changed the stringPluginName in DEF_CLASS2. Seems to work here, the vst3 gets detected. I tried the hello world example from the sdk without the gui stuff. However found out that it crashes on saving a song, it's fixed now. 

Re: VST3 DLL name
i will try to replicate this again, maybe the issue was on my end and i didn't realize that type-to-find-machine will go by the stringPluginName that didn't match. or maybe i scanned the wrong shell. i called the dll something like "test.vst3" and the stringPluginName "test2", but it's also possible that i already had a test.dll vst2 which could interfere with this. sorry it's all a bit blurry because getting vst3 sdk / example to work brought me to the edge of insanity and really got my blood boiling. i still can't believe they came up with this mess, all i wanted was the c-like vst2 with per-sample automation.