Kjetil Matheussen

Anyway, I've marked ZamDelay as unstable in Radium, so the case is closed on my end. Please let me know if you need more help.

In the JUCE AudioPluginHost program, none of the ZAM vst plugins are accepted by the scanner (it's not the same scanner that is used in Radium). In Renoise, the scanner...

``` wget https://github.com/juce-framework/JUCE/archive/5.4.7.tar.gz tar xvzf 5.4.7.tar.gz cd JUCE-5.4.7/extras/AudioPluginHost/Builds/LinuxMakefile/ make -j3 ./build/AudioPluginHost ```

Guess it behaves differently because of memory corruption. Sometimes it works, sometimes not. And in your code, calling "effOpen" is taken care of by DISTHRO, so that shouldn't explain the...

I'm compiling the plugins like this though: ``` [kjetil@localhost dpf]$ git diff diff --git a/Makefile.base.mk b/Makefile.base.mk index d8623e6..15c42f3 100644 --- a/Makefile.base.mk +++ b/Makefile.base.mk @@ -146,7 +146,7 @@ else # Common...

> And in your code, calling "effOpen" is taken care of by DISTHRO, so that shouldn't explain the assertions. Above it should say: "calling "effOpen" twice".

I was testing ardour/renoise/juce with the call to std::free commented out, as I wrote above. When I reinserted that line, the scanner in Ardour doesn't accept ZamDelay either. Could it...

The Vitalium VST2 plugin crashes in Radium when closing the GUI. It's inside 'dynamic_cast' here as well so I guess it's the same bug: ``` Thread 18 "radium_linux.bi" received signal...

Also, the scanner in Ardour doesn't recognize the vitalium VST2 plugin (don't know why), so I can't test there.

Problem is that the LinuxComponentPeer instance has been deleted. As a work around at least it probably works to check that peer is in Destop::getInstance().peer (which is of type Array)...