On Mac 10.10.5
I have tested this the Demo Host in Juce 3 and Juce 4 (latest build) and it hangs.
This does not happen in other hosts. I just tried it in Reaper and no problems.
Are you sure this isn’t some anti-piracy stuff in that plugin which is detecting the debugger? Try a release build or Tracktion just to make sure before assuming it’s a juce bug.
No because it loads many other instrument samples and I tested it with a release build. It just hangs on GPO4>Standard>Flute Solo Flutter instrument and a few others. I am trying everything I can to get more information. I just downloaded Tracktion, to test it. I’ll let you know as soon as I get a result.
It does not crash with Tracktion.
To be specific it hangs in setCurrentProgramStateInformation … AudioUnitSetProperty
Well, Tracktion obviously uses the juce wrapper, and if it’s locking up inside the plugin’s code, then there’s not much we could do about it, the plugin devs would need to have a look at why their code isn’t working in this one particular host.
This makes no sense at all. If it works in Tracktion and not in the host, then the Tracktion code is different from the demo host is some way. If you want to send me the Tracktion code, I’ll march through it and tell you the different. Ha Ha just kidding, but that is what is needed. Yes it is painful, but it needs to be done.
And why do you always blame the other parties? It works in every other host, so it something in the juce code. My old simple host code does not have a problem with it.
Connect the dots.
Sorry to be so direct, but this kind of answer is killing me. I bet I have at least 20 work arounds in the juce code and I don’t tell my customers, the problems are with the juce code. I fix them. Problem is this one I can not fix.
If I am wrong then I will deeply apologize, but I am 99.9% sure it is juce code.
After 8 hours of trying and hacking I have found the juce bug. As I say juce bug.
AudioPluginInstance::PrepareToPlay is being called (which gets information from the plugin ) before the plugin has finished loading the chunk. I guess for this particular sample this caused it to hang. Please tell juce code to wait it’s turn!
To make my code work I blocked AudioPluginInstance::PrepareToPlay during loading and then called it after the data was loaded from the outerblock.
NOW can someone there fix this properly.
Hello - sorry, only just saw your post…
Yes, of course we can fix our demo code to avoid this particular race condition, but this isn’t a JUCE library bug, so us fixing the demo won’t magically fix your own app, or anyone else’s.
Obviously hosts like Tracktion will already have mechanisms to avoid clashes between plugin playback and state changes, but there’s nothing we can do in the library to enforce that behaviour.
Something we can do is to add an assertion if prepareToPlay gets called before setStateInformation returns, so that’ll at least stop other people falling down the same hole in the future.
But as for how you should deal with this in your own app, that’s up to you to decide based on what’s most appropriate in your case. Perhaps you should stop all playback during loading, or maybe you could start and stop individual plugins while you load their state… Depends entirely on what makes sense for you.
That’s an answer I can live with. Actually all playback was stopped during the call. I believe the juce code sent an asynchronous update of some kind once the plugin was created that called prepareToPlay. I could not not find where it occurred.
I talked to the guys at Plogue (ARIA) and they are going to put in a mutex so the plugin will not hang if the call is made before the state is fully loaded.
One more things. How can I make a effVendorSpecific call to an Audio Unit like the VSTPluginFormat::dispatcher.
Can’t seem to find the equivalent.
VSTPluginFormat::dispatcher() is maybe what you need?
That only works for VST instruments.
What about Audio Units?
I have hacked the AudioProcesor base class to provide a dispatch but think there is probably a better method.
Sorry, misread your earlier post. No, haven’t got anything similar for AU.
But the way to do it would be to add a static method to AudioUnitPluginFormat, like the VST one, not to involve the AudioProcessor base class. This isn’t the kind of thing that can be made generic across plugin formats.
Ah, hang on, I forgot…
We have getPlatformSpecificData(), which can be used to get the AudioUnit object, e.g.
auto audioUnit = (AudioUnit) plugin->getPlatformSpecificData();
OK both ideas will work, the second being the easiest.
