Windows VST plugin not showing up for some people


#1

Hi all:

I am having a bug with my plugin, where the Windows VST isn’t showing up in some people’s plugin list, even after they install it in the correct directory. The reports are all coming from Windows XP systems, and they are invariably using Cubase - but the plugin doesn’t show up in their other, non-Steinberg apps.

The users that are having the issues have installed the VC8 Runtime, so this isn’t the issue (as far as I can tell).

Any ideas? It is hard to fix a bug I can’t reproduce here, but maybe others have encountered it.

Thanks,

Sean Costello

P.S. The latest beta versions of the plugin are linked from my blog:

http://valhalladsp.wordpress.com/2010/03/24/valhallafreqecho-1-01-beta-available/


#2

My first thought was also the VC8 runtime, but you’re a step ahead on that… Nothing else springs to mind, I’m afraid. The thing to figure out would be whether the DLL’s failing to even load, or whether it’s loading and then crashing during start-up. If you’ve got a friendly beta-tester you could send them a version with logging, and see how far it gets…


#3

Alrighty. Any pointers for logging? I have always used the debuggers in the compiler, or the crash reports in OSX, so am unsure what to do so a customer can send me a useful report in Windows.

Thanks,

Sean Costello


#4

For quick-and-dirty logging like this I normally just pipe some messages to a file on their desktop.


#5

Alrighty! It looks like I figured out the issue, and it is an interesting one:

The problem was having a polymorphic plugin for both VST and RTAS. For at least 1 user, this caused the VST to not load. I created a new project, where all RTAS files and references were removed, and built a “pure” VST. This fixed the issue for the user in question.

My guess is that the plugin was looking for some external Digi libs to load, that just weren’t there. Or maybe RTAS requires some system libs that some people have, but not others. If someone wants to look into this, fine, but I have a solution that works for now.

Here’s my one beef about the whole process: I would have preferred to have separate build options within the same VC++ solution. However, since I have to change values in JucePluginCharacteristics.h, I worry that I would end up linking to the wrong file, or that I can only have 1 named instance of the file (I didn’t test this, but I know that I can only have 1 file with the same name in an Xcode project). Any suggestions about how to have separate, clean VST and RTAS builds inhabit the same VC++ project/solution?

Thanks,

Sean Costello

P.S. Gary Newby (gnjp) was the person who first pointed out the issue with Digidesign .dlls not being loaded on KVR:


#6

Interesting, and surprising, as I’ve never heard of problems like that before. It might be worth having a quick look at the dll in a dependency-viewer to see what dlls the RTAS build was relying on.

Have you looked at the new jucer’s plugin options? It makes it easy to flip switches to select which plugin types your project will build, but if you can think of extra options that it could do to make your life easier, it could be something worth adding.


#7

[quote=“jules”]Interesting, and surprising, as I’ve never heard of problems like that before. It might be worth having a quick look at the dll in a dependency-viewer to see what dlls the RTAS build was relying on.
[/quote]

I totally understand why this bug would be hard to replicate for developers. If you are developing RTAS, by definition you will have Digidesign libraries on your test system - unless you dedicate a computer to VST testing only. If you aren’t developing RTAS, the issue won’t come up.

In the next few days, I will take a look at my old build and see what dlls it was looking for. If anyone wants to try it, you can download the older version of the VST at

http://www.valhalladsp.com/plugins/ValhallaFreqEchoMkI_1_01_Win_VST.zip

[quote]
Have you looked at the new jucer’s plugin options? It makes it easy to flip switches to select which plugin types your project will build, but if you can think of extra options that it could do to make your life easier, it could be something worth adding.[/quote]

This might be a pain, but what about the option of generating separate projects for each plugin type? I’d like to think that there is a cleaner solution, but my Visual Studio skills are a bit rusty at this point.

Sean


#8

Of course. But I’d expect that everyone who’d released a public plugin would have hit the same thing you saw, and there have been plenty of those… Maybe this is a recent change to the RTAS SDK or a difference in the way you’ve compiled the RTAS libs?


#9

Of course. But I’d expect that everyone who’d released a public plugin would have hit the same thing you saw, and there have been plenty of those… Maybe this is a recent change to the RTAS SDK or a difference in the way you’ve compiled the RTAS libs?[/quote]

I’m using the PT_80 SDK, which is probably pretty common. I think that I linked to the precompiled RTAS libraries that came with the SDK - are there projects to build these libs? I’m referring to the .lib files in the lib folder under Winbag - these all were last modified in late 2008.

I wonder how many VST/RTAS developers are working out of the tip, instead of with one of the stable release versions of Juce? Many of the older Juce plugins wouldn’t be using polymorphism - it’s been in the tip for a little over a year.

I wouldn’t rule out some weirdness on my part, with regards to setting up the Juce project. However, I didn’t get terribly creative with the project - I followed the readme directions pretty closely.

[EDIT} OK, now I am wondering if I may have linked the RTAS libs into my project incorrectly, or maybe not at all. If these libs weren’t linked in properly, would the .dpm be able to load properly in Pro Tools? What sorts of problems would this cause?

Sean


#10

Does it come with precompiled libs? I seem to remember building them myself…

I think that if you didn’t link to the RTAS libs, your dll wouldn’t actually link at all.


#11

I’d love to get my hands on the RTAS SDK but for some reason digidesign does not want to give me one. Anyone willing to help out ?


#12

[quote=“jules”]Does it come with precompiled libs? I seem to remember building them myself…

I think that if you didn’t link to the RTAS libs, your dll wouldn’t actually link at all.[/quote]

Yeah, that’s what I figured.


#13

I’m revisiting this issue. I had a user unable to load my plugin when switching from Win XP SP3 to WIn XP SP2. Installing the VC8 Runtime fixed things for them.

Two questions (well, one question and one request):

  • Does the VC8 Runtime issue go away when using different compilers, such as VS2003 or VS2008?

  • Would it be possible to offer an option in the new Jucer to generate different targets for the different plugins? e.g. for the Windows build, you would have 2 targets, VST and RTAS, where each target only links to the required libraries. For OSX, you would have 3 targets, VST, AU and RTAS. This would allow developers to keep all their work in a single project per OS, while avoiding the issues that seem to be linked to the polymorphic plugins (the VST issues I reported above, as well as the AU/VST GUI issues in Ableton LIve on the Mac).

Thanks,

Sean Costello


#14

AFAIK they’re all the same in that respect.

Not without a huge amount of effort! And since the only problem I know about that’s caused by the polymorphism is the Mac obj-C linkage issue when you load the same VST and AU simultaneously, I don’t really see why this would be worth considering?


#15

Not without a huge amount of effort! And since the only problem I know about that’s caused by the polymorphism is the Mac obj-C linkage issue when you load the same VST and AU simultaneously, I don’t really see why this would be worth considering?[/quote]

Well, I’ve had issues with the VST plugins linking to the RTAS .dlls (see: the thread above). Add that to the obj-C linkage issues for VST and AU plugins, and that is 4 plugin formats that I need separate builds for, out of 5 total formats. I know that I can create separate projects via the new Jucer, but my guess is that anyone who builds VST and AU plugins will need separate projects to deal with this issue, or face having issues in Live. Having separate targets would be very useful for those people that use Juce for audio plugins.

Sean Costello