OS: Mac OS X El Capitan Plugin Type: VST (though problem was replicated in AU format) Stack Trace available: no (can’t get XCode 7 to cooperate with me on this) Juce Version: 4.2.3
Brief Description of Problem:
Amplitube will only load into the AudioProcessorGraph once. After being deconstructed, if you try to reload it again, you receive an error box saying the VST-2 failed to load. Amplitube is the only plugin that exhibits this behavior. All others I try work reliably.
Detailed Description of Problem:
At this point, I’ve been able to pin the problem to be revolving around the effect variable in the file VSTPluginFormat.cpp. If you look in the VSTPluginInstance constructor, then of course you will see that the effect variable is set by the macro JUCE_VST_WRAPPER_INVOKE_MAIN. Unfortunately, on the second loading of Amplitube, the effect variable remains a nullptr. I’ve tested the ModuleHandle for any discrepancies in Amplitube’s loading information but everything remains consistent that I can tell unless there is something I’m missing.
The Big Question:
What could possibly be going on that would make effect remain a nullptr on subsequent loadings of Amplitube? Are there any details that Amplitube may be fiddling with such as _fpreset()?
Why it matters:
I’m building a separate plugin host tailored for guitarists’ needs. Amplitube support is a high priority.
I don’t think that there is much we can do about this. I did some tests myself. In fact, if you load any plug-in format of Amplitube (let’s say VST), unload the plug-in and load any other plug-in format (AU) of Amplitude, it will fail. As the code for loading VSTs and AUs is very completely different you won’t get far by debugging the VST or AU code. I suspect there is some issue when unloading and re-loading their dynamic library. This will be difficult to find out without their help.
It’s worth filing a bug with them - I’ll also try to contact them via our channels and update this post once I know more.
We have experienced the same issue for a while. There are issues with many ikmultimedia plugins.
As fabian says, there is not much we can do with out the help of the developers, who again blame us cause it works in other hosts… so we are screwed basically.
Here is a short list of other plugins you might get complaints from your users on:
IK Multimedia products have issues.
Omnisphere 2, (conflicting reports)
NadIR v1.0.2 x64
INA-Grm (conflicting reports)
Korg -Legacy Cell
Roland SH-2 (One crash report)
Antares Harmony Engine vst3
You will also get complaints on Asio drivers crashing:
Wow, thank you for this list. Please don’t get me wrong. This may very well be down to JUCE bugs. However, especially, the IK Multimedia bug will be nearly impossible to track down without the help from IK Multimedia. We’ve reached out to IKMultimedia and I’m sure will get an answer soon.
Wow, I appreciate the responses! I just want to let you all know that I too am reaching out to IKMultimedia. I opened a support ticket yesterday and haven’t heard back yet but I’ll keep everyone posted on what I end up hearing from them. Even though I hate for others to be dealing with the same problem, it does help me feel better to know I’m not alone on this one. One way or another we’ll get this solved
Some of the GRM Tools plugins have a problem that the GUIs of the plugins don’t work right unless the audio processing function is regularly called. And even worse, for example the GRM Spaces plugin requires that the audio processing is called at least once before the GUI is shown at all. If that is omitted, the GUI will initialize in a state that makes some options not available.
Thanks for checking this out Fabian. @Xenakios, I did not know that, I can’t remember what the reported problem was but I will check it out.
On a general note, the problem is that these issues are not really Juce bugs per se, they are usually bugs in the plugins that just sometimes show in juce hosts.
Data from our beta testing shows around 3500 different plugins (plugin descriptions) that loaded fine, so statistics are on our side.
The plugin developers check their product in protools, cubase, reaper, etc and if it works there they will say "there are no problems with our product"
When contacting plugin vendors I have had very different results, some say "Oh we have a stupid bug there, we will fix it"
Some can help us with a workaround. Most don’t care really. none of the juce hosts are “big” enough that it would justify their added development time I guess.
Unfortunately I’m starting to see what you mean Nikolai. It’s been about 4 days and my support ticket with IKMultimedia has not received a response yet. Not even them emailing me just to let me know they are on it. I’m not even asking them to change anything, I’m the one making the adjustments for their sake .
I wonder what FL Studio is doing because from what I’ve gathered, Amplitube works fine on there. Going to download the trial version today and try confirming this on the Mac side (I know it works fine on Windows, just need to test their Mac version).
Oh man I remember the first time I reached out to IKMultimedia they gave me that literal exact same response! Then of course never heard from them again. I’m cheering for Fabian, hopefully he can make them pay attention.
Finally got a chance to try this out on a Windows box and interestingly enough, this bug does not seem to exist for the Windows platform. I’m going to spend some time digging through the ModuleHandle open and close code to see if there is anything that might stick out as to what is causing the effect to do this for Mac since the code for initializing on the different platforms is so different.
I feel like there has to be a way to make this work. Too many DAWs and other plugin hosts are able to run Amplitube. Even if IKMultimedia isn’t willing to help, surely there might be some angle to make this work. I’ll keep digging.
I don’t have Amplitube to try this myself but if this happens on OS X but not on Windows it might be related to the GUI. The next step I’d try would be to open a generic (GenericAudioProcessorEditor) GUI instead of the one supplied by the plugin and check whether the error occurs here, too.
Unfortunately I’m unable to get that far on the second loading of Amplitube so I can’t reach the point to be able to do that test. However on the first loading of Amplitube I can load both the main and generic UI just fine.
I suppose to be more specific, the point the plugin loading breaks from the perspective of VSTPluginInstance is the moment JUCE_VST_WRAPPER_INVOKE_MAIN is called. The purpose of JUCE_VST_WRAPPER_INVOKE_MAIN being to set the AEffect* callback (i.e. the variable effect). Essentially, at this point both effect and module remain as nullptrs.
For shortcut’s sake, the code for JUCE_VST_WRAPPER_INVOKE_MAIN is just one line… JUCE_VST_WRAPPER_INVOKE_MAIN effect = module->moduleMain (&audioMaster);
Spent a fair amount of time going through the code for ModuleHandle (the class for module) and tested the initialization code for the portions defined for JUCE_MAC but nothing of it. Even on the second loading of Amplitube it seemed to work fine through that stage of the loading process. All the data appeared to be in place, didn’t see anything suddenly rendered null that wasn’t supposed to be null.
For now I’m going to keep trying to dig deeper into anything that looks like dynamic library code related to the Mac side since it’s working fine on Windows.
Oh and just for the record, I have updated to Juce 4.2.4.
I’m in contact with IK Multimedia. The culprit is the way JUCE loads and unloads bundles. Basically, IK Multimedia require that their bundle is completely unloaded when the last instance of the VST is unloaded. Bundle unloading is a bit tricky when it comes to a cross-platform library like JUCE:
The problem is that JUCE cannot know if some other plug-in (for example NI’s Maschine) also loaded an instance of Amplitude. Therefore, we cannot force unload the bundle (via CFBundleUnloadExecutable) when there are no more JUCE instances of Amplitude lying around - as we would release Maschine’s bundle under it’s feet.
There is a solution for this: simply use the reference counting system of CFBundleRef. When JUCE uses the bundle we increment the reference count and we decrement it when we are finished with it. If there is no more instance of Amplitude in any other plug-ins (like Maschine) then OS X will unload the bundle. JUCE needs to take this approach to be compatible with plug-ins like Maschine.
However, there is a caveat: OS X also has something called a bundle cache. It will keep bundles in an internal cache (see discussion here). This means that the reference count will be two when loading the bundle for the first time (one reference is basically the reference that JUCE can use, the other one is for the entry in the cace). Now, even if we release the Amplitube’s bundle when the last VST instance is unloaded, OS X will not necessarily unload the bundle - which seems to be required by Amplitube. To make matters worse, we have no control on how long the bundle will be retained in OS X’s internal cache.
To make a long story short: can anybody think of a good workaround for this use-case?
Update: IK Multimedia is in touch and we are looking for a bug-fix or potential workaround for this issue.
I just wanted to say thank you for opening a dialog with them to seek a resolution. Too often in situations like this, vendor A says “It can’t be our problem, lots of other products work just fine” and vendor B says “It can’t be our problem, lots of other products work just fine” and anyone depending on A and B working together are left without any way to resolve the issue. Whether the fix comes down to a change in A’s product or B’s, BOTH stand to benefit from gaining a full understanding of the incompatibility and seeking a resolution.