Kjetil Matheussen

I had to modify the patch a little bit. I also wanted it to resort to using universal package if individual package does not exist: ``` diff --git a/tools/osxcross-macports b/tools/osxcross-macports...

Backtrace: ``` Program received signal SIGSEGV, Segmentation fault. 0x00007ffff60ab0dc in free () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff60ab0dc in free () from /lib64/libc.so.6 #1 0x00007ffff547e33c in DISTRHO::String::~String (this=0xbbeae0, __in_chrg=) at...

If I comment out the call to 'std:free' for the above crash, ZamDelay is accepted by the scanner. However, when I try to load the plugin into Radium, I get...

See also discussion here: https://users.notam02.no/~kjetism/radium/forum/viewtopic.php?f=7&t=279

> do you also get crashes with the rest of zam-plugins? No, just this one. Tried all the others. > That would be an interesting test. I'm sorry but I...

> Yes, that's really strange. Oh, yes, you said, the same thing happens in frame 13 and 14 too. And that's in JUCE. This looks really strange. The destructor calls...

Hmm, I think frame 13 and 14 may be legit. It's some weird JUCE code that schedules deletion of the vst instance to happen in the message thread, and then...

> This causes the destructor to be called twice. No, that doesn't make sense. I guess the destructor is only called once, but the method name in the bactrace is...

> Also when it hits line 1138, it calls the destructor again ? Good point. I have no idea.

I tried to add a call to abort() in DISTRHO::PluginVst::~PluginVst, and the ZaMaximV2, to provoke bactrace on a plugin that apparently works fine, and both the same double calls to...