Ive noticed that in your example application PluginHost as on the prebuilt OSX dmg that the host freezes when loading
a patch set up for the Garritan Steinway Piano plugin which uses the Plogue ARIA sampler engine ( latest 1.04/ ARIA 1.111 version ).
This is for the VST version of the plugin.
The plugin itself loads up ok, its only when using file open to load a filtergraph that one gets a problem. It seems to get stuck when attempting to load one of the Steinway wav files:
“SoftPedDown1.wav”
However Traktion 3 seems to load and save settings for this plugin fine. Is there a difference between the VST host in your Pluginhost example and Traktion ? i would have assumed both use the same JUCE VST hosting code.
The demo host crashes Aria GPO Library as soon as you try to connect an output to an audio input. The host also crashes when exiting even if no connections were made to the Aria Player. The host also crashes when loading the CSR Hall effect and the Sonivox SoundStage library in debug mode. The SoundStage is caused by it’s copy protection and debug. CSR Hall crashes because of a registry error.
The Plogue Host handles all this. Can something be done to make the host more stable? I am planning on using the Juce Host, but need it stable, of course.
How could I possibly know what to change in the host in order to avoid those plugins crashing with internal errors?
If the owners of those plugins could tell me exactly what the host is doing that their code isn’t expecting, then it may be something that could be changed, but I’m not psychic!
And BTW try the release build before assuming there’s a problem. Some plugins crash deliberately because they have piracy detection code that checks for a debugger.
I did try it in the release mode. The is why I mentioned that SoundStage only crashes in Debug mode. I understand your frustration with the problems with players. I wrote a host on the MAC side and had the deal with a Native Instruments problems. I remember sending them an email explaining the crash but by the time they responded, I had figured a work around, and my app didn’t crash.
Now let’s be fair and take some responsibility. All the other hosts don’t crash with the Aria Player, even the “VSTHost” from http://hermannseib.com, which we all know helped to start this whole VST host thing. This is a very good indication that the juce host is doing something wrong or more likely, not handling plugin errors safely. I will investigate when I have more time and try to solve the problem.
I suggest at a minimum juce could do what other hosts do. Save the name of the plugin before initializing it and if the plugin does not come return after the initialization, the engine will ignore the plugin the next time it tries initializing plugins. Once the plugin ha been fixed there should be a way to undo the saved state. I do plan on using the Juce host, so I guess I’ll be fixing the problem if no one there does.
P.S. I talked to the guys at Plogue a few years back about writing a host and they said one of the more important issues is to test the host with every possible plugin and trap the problems with the ones that don’t obey the VST spec or initialize properly. So in your defense maybe this is to much to put in the host code and whoever uses the host code should be doing the dirty work.
I’ve spent/wasted a lot of time over the years chasing problems like this, and they almost invariably turn out to NOT be any kind of mistake in the host, but just plugins that contain flakey code which expects things to happen to it in a very precise order. The developers will have tested them in a couple of hosts where by chance things get called in a particular way, but when you put it into a host that does something very slightly differently, they have problems.
Unfortunately, when there’s no actual mistake to find in the host, the only way to “fix” these things is to randomly jiggle the host’s behaviour around until it happens to work. (Often breaking some other plugins in the process!) That’s the kind of tedious thing I spent days doing back when I was writing Tracktion, but I’m not prepared to do it any more!
You think it’s my responsibility to work around bugs in other people’s code? Someone’s code is crashing here, but it’s not mine!
That’s what the deadMansPedalFile parameter is for, when you create a PluginDirectoryScanner.
I do agree with you. I know the problem is is the plugin’s code, but the responsibility in the host to try to get around it and not just point blame. Remember we are paying for a host that works with plugins, not just a few here and there. I paid a lot of money for the host in my PC app because it worked and did not crash with faulty plugins with a few exceptions. They put the fixes for the faulty plugins in the host.
This is what we do when we write real applications. We find solutions not blame. As I read the forum, I read plenty of places where you had to write around operating problems or inconsistencies. I can’t tell you how many times I wrote fixes around bugs in MFC code, MAC OSX code, etc. So please realize what we’re saying. We love the fact that you have taken on this task of creating juce, but in order for it to work in major applications, not plugins for home use. these issues have to be addressed.
So why was it done in Tracktion, probably because it was a commercial product that needed to sell. I feel for you. Hey man I scream at Apple every time I write code for the bugs they introduce with each new OSX version. I don’t depend on Apple to fix the bugs because as we all know that takes 6 months to a year. Hey Logic 8 didn’t work with Lion. They had to put the fix in Logic 9 and not wait for the fix in Lion.
Enough whining from me and I have a serious question but I’ll send it in a private email.
I’ll do my best to fix the host code as I get a chance.
