I’m trying to look in to this but can’t get figure out how to create a json file sushi will load. I just get an error message:
Failed to load tracks from Json config file
Here’s my json file, cobbled together from the examples:
"host_config" : {
"samplerate" : 48000
},
"tracks" : [
{
"name" : "main",
"mode" : "stereo",
"inputs" : [
{
"engine_bus" : 0,
"track_bus" : 0
}
],
"outputs" : [
{
"engine_bus" : 0,
"track_bus" : 0
}
],
"plugins" : [
{
"path" : "~/Documents/Elk/EngineInPluginDemo.so",
"name" : "synth",
"type" : "vst2x"
}
]
}
],
"midi" : {}
}
Can the plugin be a relative path to the sushi file? That would be simpler.
What worries me looking at your log file however is that the line Rogue call to triggerAndWaitForCallback()
is indicating the Engine object, and hence the plugin isn’t being loaded from a JUCE thread. I forget how this works in Linux but I would have thought that whatever thread instantiates JUCE, gets tagged as the message thread and then the host has to pump its dispatch loop when possible. (The other alternative is the JUCE creates its own message thread and uses that internally to pump the message thread).
Worse than that though, the second error ERROR: triggerAndWaitForCallback() unable to complete
indicates that the message thread hasn’t been initialised at all as this signifies that the async message is unable to be dispatched and complete its action.
If this is the case, nothing is going to work.
Having said all that, I was able to build and test this in the JUCE Audio Plugin Host and get similar error messages, the first of which is an assertion that fails in tracktion_AutomationRecordManager.cpp:
jassert (MessageManager::getInstance()->isThisTheMessageThread());
As suspected, this indicates that the message thread is not being associated with current thread.
On Linux there is a class: SharedMessageThread
, this seems to designate itself as the message thread with the call to MessageManager::getInstance()->setCurrentThreadAsMessageThread()
in the run()
method.
However, that then conflicts with the plugin creation which just continues on the current thread.
I’m not sure how this is supposed to work and if on Linux you’re actually getting two threads pretending to be the message thread?
To me, this sounds like a JUCE plugin client bug…