buzz forums

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?

Odd, can you tell me which vst3 are not detected so i can test them?

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.

polac wrote: ↑Sat Mar 25, 2023 9:37 pm Odd, can you tell me which vst3 are not detected so i can test them?

it's a very simple (if you can call it that when using the abysmal vst3 sdk) test plugin i wrote, and as soon as the names matched pvst picked it up. it worked fine in vsthost regardless.

Thanks for the info, as you can see i renamed Dexed to DDexed and the plugin name is Dexed, still seems to work. I'll try to compile a test vst3 then, it will be lots of fun. Cannot see what could cause this yet, have to debug this crap.

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.

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.