It seems like the tip’s PluginHosts’s OS X plugin scan code does not do its job well. It often crashes or hangs, it doesn’t matter if VST or AU.
With D16 Drumazon (seems to be a JUCE plugin itself) I get: (The plugin does work in Logic)
#0 0x90c756e4 in objc_msgSend
#1 0x002b6b38 in juce::NSViewComponentPeer::NSViewComponentPeer at juce_mac_NSViewComponentPeer.mm:883
#2 0x002b6ffa in juce::Component::createNewPeer at juce_mac_NSViewComponentPeer.mm:1715
#3 0x1734815f in juce::Component::setColour
#4 0x17379a03 in juce::LookAndFeel::createSliderTextBox
#5 0x17388993 in juce::Slider::lookAndFeelChanged
#6 0x173893f1 in juce::Slider::Slider
#7 0x171a4cff in GFXKnob::GFXKnob
#8 0x171c4a61 in BasePluginEditor::importPluginEditorFromXml
#9 0x171c4f9d in BasePluginEditor::importPluginEditorFromResource
#10 0x171c5a5b in BasePluginEditor::BasePluginEditor
#11 0x17424680 in InstrumentEditor::InstrumentEditor
#12 0x1741b227 in DrumMachineEditor::DrumMachineEditor
#13 0x174276f0 in DrumazonEditor::DrumazonEditor
#14 0x17424899 in Drumazon::createBasePluginEditor
#15 0x171c090d in BasePlugin::initialize
#16 0x17416155 in DrumMachine::initialize
#17 0x171bae57 in createPluginFilter
Whenever I see a crash in an obj-c dispatcher, the main suspect must be an objective-c class name clash - did you make sure your host has the JUCE_ObjCExtraSuffix value set?
Is the sony oxford also a juce plugin? The entry point names look like the old juce-style carbon naming convention. Maybe a quick ‘strings’ on the binary might reveal some clues about that.
I tried with your plugin host and it’s the same. I just compiled the plugin host XCode project as is without any modification, same result. Funny thing is it doesn’t always happen, just sometimes. Don’t think the Sonnox stuff is JUCE-based, up to you to judge that.
Can’t think of any other clues, I’m afraid… Plugins can be frustrating to debug from the outside - it might actually be worth pinging the makers and asking if they’ve tried it themselves.
No, I’ve not tried them. The main reason I suggested pinging them is that you can sit for days trying to figure out why a plugin is crashing, and get nowhere… (I’ve wasted far too much of my life doing exactly that, which is why I’m reluctant to offer to help with this).
And just because a plugin works in every other host doesn’t mean that it’s the host’s fault that it’s crashing! I’ve often seen hosts do perfectly sensible things that cause plugins to crash for mysterious internal reasons that you’d be powerless to figure out from the outside.
C’mon, at least please try the Sonnox one. It crashes EVERY time. If this was just some stupid amateur-freeware-plugin crashing, I’d say “ok, I understand your point” - but this is a kind of ‘reference’ plugin that’s crashing. I’m sure everybody in this forum will appreciate your time well spent.
.apart from the client who’s paying me to do some other work this week! If I was sure it’d only take 10 mins then I’d take a look, but investigating plugins always ends up dragging on for hours/days, which I can’t spare right now! I’ll have a look as soon as I can!
Sorry, but trying to track down bugs in other people’s plugins, without the source code, is a low priority for me! Contact the makers and tell them - they should be able to simply catch it in the debugger and see what’s happening. If I investigate, I could waste days and may discover nothing at all.
[quote=“zamrate”]It seems like the tip’s PluginHosts’s OS X plugin scan code does not do its job well. It often crashes or hangs, it doesn’t matter if VST or AU.
With D16 Drumazon (seems to be a JUCE plugin itself) I get: (The plugin does work in Logic)
#0 0x90c756e4 in objc_msgSend
#1 0x002b6b38 in juce::NSViewComponentPeer::NSViewComponentPeer at juce_mac_NSViewComponentPeer.mm:883
#2 0x002b6ffa in juce::Component::createNewPeer at juce_mac_NSViewComponentPeer.mm:1715
#3 0x1734815f in juce::Component::setColour
#4 0x17379a03 in juce::LookAndFeel::createSliderTextBox
#5 0x17388993 in juce::Slider::lookAndFeelChanged
#6 0x173893f1 in juce::Slider::Slider
#7 0x171a4cff in GFXKnob::GFXKnob
#8 0x171c4a61 in BasePluginEditor::importPluginEditorFromXml
#9 0x171c4f9d in BasePluginEditor::importPluginEditorFromResource
#10 0x171c5a5b in BasePluginEditor::BasePluginEditor
#11 0x17424680 in InstrumentEditor::InstrumentEditor
#12 0x1741b227 in DrumMachineEditor::DrumMachineEditor
#13 0x174276f0 in DrumazonEditor::DrumazonEditor
#14 0x17424899 in Drumazon::createBasePluginEditor
#15 0x171c090d in BasePlugin::initialize
#16 0x17416155 in DrumMachine::initialize
#17 0x171bae57 in createPluginFilter[/quote]
I got exactly the same kind of stack and problem with another D16 plugin, Nepheton.
The weird thing was that the plugin was working in juce plugin host application, but crashing in my host app.
I tried to recompile everything with a custom JUCE_ObjCExtraSuffix, but it did nothing. Which I expected because the suffix was already set on some kind of hexa string (I suppose it is generated by Jules at some point in the release), and I doubt the D16 plugin uses exactly the same string. Besides, if it was working with the plugin host application, why wouldn’t it work in my app with the same underlying juce library? The only difference is that my app links statically and the host app uses juce amalgamated…
Then I saw that the plugin host application project had the option to hide the symbols by default. I tried to recompile my project and all its dependencies with this option and now it seems to work.
I’m not a linker guru, so I don’t really understand why it would change anything. I thought symbol visibility was only for dynamic libraries? Does anyone have the Knowledge about that?
I’m still not sure it was this change that did the trick but I don’t see what else I did that could have make it work…