While playing around with the plugin host, I was trying to scan some plugins, and this free VST effect “triggered a breakpoint” in PluginHost (when attempting to close it): Combo.dll (from mda).
I’ve attempted debugging, but can’t seem to be able to figure out why since I’m not familiar enough with the VST code… so here’s a stack trace.
If I click “Continue” in VS, I can oddly still see the plugin in the list.
[attachment=0]mda Combo - The Crasher.png[/attachment]
Also, deleting an instance of this plugin when used as a filter causes a crash of the plugin host… at the same method call (juce::ModuleHandle::closeEffect(juce::AEffect * eff) Line 454).
This happens in Debug… and crashes the app when in release.
Upon a further attempt of understanding the VST code while walking through this issue; it seems to be related to the plugin itself… Although such wouldn’t explain why the DAWs I have at hand can load, use and close this plugin fine.
There are many plugins out there that are written with dodgy assumptions about the exact order or timing with which their functions will be called, so they end up working ok in the host that they were written for, but get fragile when other hosts deviate slightly from that behaviour.
The juce host wrapper definitely doesn’t do anything silly or unreasonable, so I think that the tiny number of plugins that still fail are probably just a bit flakey. Unfortunately to attempt to guess what it is that they don’t like, and to change the wrapper to accommodate that is almost impossible without being able to debug them.
I got in touch with the developer of the MDA plugins (Paul Kellett) - he looked into it rather speedily! Here’s his reply to my e-mail letting him know that his plugin somehow crashes the plugin host:
Paul is referring to the following method: juce::VSTPluginInstance::getVersion().
I did a bit of research and came across the following in the VST code’s documentation (see aeffect.h - line 180):
struct AEffect
{
//[...] code before here
VstInt32 version; ///< plug-in version (example 1100 for version 1.1.0.0)
//[...] more code after
}
All juce-based plugins will use base 16 to build the version number; if other ones are using base 10, then that makes it things a bit tricky. If I change the host to use base 10, all the juce ones will look wrong. Hmm. Yeah. Not sure about that…
Well I think the Juce VST host is one of the few hosts that actually show the VST version number. FL Studio and Audtion don’t ever show it. Also I’m guessing most people were probably using a text label to put there version number in their plugin rather than using the code based plugin version number directly. This is probably why it has gone unnoticed all these years.
If all other hosts are following the VST spec properly and using base 10, then all the juce based vst plugins are showing to wrong version in all those hosts. Additionally since it is causing the juce host to crash, this is definitely a bug that should be fixed on the plugin and host side.
I also see that you changed the juce_AudioPluginModule file to use the decimal format instead of hex… that may not be good since AU plugins utilize base-16 for version numbers (see the Audio Unit Identification section)…