First off @thetechnobear before anything. Thank you so much for taken out the extra time to do a quick analysis and offer suggestions/insight/anything. I take everything you say as precious as diamonds. So thank you so much.
Ok. So what do we have here. It appears @wavejockey i believe has reported a write bug causing a crash.
Now I obviously don’t have the same preset set up as him. But when I perform a write I do not crash. But again I chalk this up as the classic, “well it works on my machine” kinda thing.
You mentioned you think you might know what’s occurring.
you’re welcome, I happy to help all percussa users (as much as I can with time available etc)
as I said, I don’t link jumping to conclusions, esp on other people’s code, (synthors or yours), frankly, I have a tendancy to blame my own code, unless I can ‘bring receipts’
so lets take a step back…
have you seen this? i.e. do you have a stack trace?
a stack trace would be super helpful… Id like to see the entire callstack on every thread when it crashes.
this is what we need to go from ‘hunch’ to more evidence based analysis.
without that, I just took a quick look to see if example was doing anything, a bit different from how I would… (and then went from there to see if you did simlar, which is natural thing for devs to do), and is all I could do really… (ok, except downloading your repo and debugging ;))
what I noticed was…
PluginEditor::PluginEditor(PluginProcessor &p)
: AudioProcessorEditor(&p), processor(p) {
// stufff....
startTimer(50);
}
void PluginEditor::timerCallback() {
for (int i = 0; i < nScopes; i++) {
in[i]->repaint();
}
for (int i = 0; i < nScopes; i++) {
out[i]->repaint();
}
// repaint our own canvas as well
repaint();
}
and in your code…
PluginEditor::PluginEditor(PluginProcessor& p)
: AudioProcessorEditor(&p), processor_(p)
{
// stuff
startTimerHz(30);
}
PluginEditor::~PluginEditor() { stopTimer(); } // !!
void PluginEditor::timerCallback()
{
// Comp editor scope: push new data each frame
if (compEditorOpen_) {
compScopePush(processor_.getCompDisplayInputPeak(),
processor_.getCompGainReductionDb());
}
/// stuff
}
Its the use of Juce timer that is the concern, and something I do NOT do.
its a complex topic and one Id need to refresh my memory on, but I have had issues in the past.
to do with the juce message manager, and loading in as shared libraries, etc etc…
(frankly, Juce is pretty ‘fragile’ in this area, its horrible code)
the reason the demo does it, is it dates back to when Synthor used Juce, and so had a message manager - so (due to above) was shared with vsts. that relationship changed when Synthor moved away from Juce.
anyway, the point being, iirc, stopTimer() is an aync call, it just tells the Message Manager to stop the timer…
thats not normally an issue, (and a common juce practice), since message manager runs on the UI thread… but that is NOT guaranteed on the SSP, which has NO relationship to juce at all.
so you could end up with a race condition where an ‘inflight’ timer callback could get called after your processor/editor have been destroy. (hence why Im interested in a stack trace)
however, there is a possibility this is NOT the case, and that is Id need to double check if/when the message manager thread is created on the SSP… but as I said, thats not a quick 5 minute code check … hence why this is just an idea/theory.
BUT, the good news is…
there is NO reason for you to use the timers… renderDisplay is calling you each frame anyway, so its unnecessary.
iirc, I do have this in my SSPUI.cpp class, but this is ONLY used on the desktop/VST, basically its my ‘wrapper’ I use for testing, but its not used on the SSP hardware.
iirc, I needed on desktop ,as we dont have a forced render loop like the SSP, so dynamic plugins like DATA need to have their UI ‘prodded’.
anyway, thats just an idea something to explore…
ofc there are lots of other differences in my plugins, so there could be many other reasons that they are ‘ok’, and ofc, race conditions notoriously, can occur rather randomly… so you could just be ‘unlucky’.
also, Id say, whilst Synthor may not always do things the way I would (naturally, all developers have their ‘own way’), I think its well engineered at a tech level, and Ive cant remember having threading issues with it (as a host), Bert is pretty hot in this area.
I think most issues I had were due to Juce, and its vagaries… frankly, to the point, like Bert Ive multiple times considered ripping it out of my code
but again, could be wrong this time… lets see a stack trace, and hopefully that’ll shine more light, and even if the above isnt the cause, might point to something else.
though its not so much about juce timer starting its own thread, rather how it ties into MessageManager. and the fact that thread is NOT the Synthor UI thread, (but, in essence, thats kind of the same thing )
anyways, painful as it is, its kinda useful to get an understanding of the vagaries surrounding Juce
iirc, this ‘relationship’ changes with Juce version, Ive had issues before when ‘upgrading’ juce, again why Id love to kick juce out of my code.
Thank you so so much! now that I have users actually using it – and hopefully what would be amazing is actually hearing or seeing someone use it on the stage… (wow what a day that would be for me to know that… ) ok, done with they dreaming, anywho before that all can happen I gotta get all the known crashes squashed… and this is basically the one I know of right now.
yeah, I love it when I see musicians using my code…
but a bit scary first few times… its one thing to run in your lab, and another when its used on stage.
esp. as most performer knows, “anything that CAN go wrong, will go wrong”.
that said, I gues no so different from having my code go live in other ‘production environements’, where Id likely be fired if it F’d up badly
there is no doubt, developers have a ‘special relationship’ with their code, even when you think you are ‘blind testing’ it… you aren’t, you have built up certain ways of using it, because you know that is how its ‘meant’ to work… they also have a different mindset, different skills, different environment (e.g.tools installed).
its why we have dedicated QA teams, but even they get infiltrated and corrupted
so thats one side of it…
the other side is just more literal, the above is (british) “Sod’s Law” which is similar to the irish Murphy’s law. basically if the stakes are higher, then its more likely that is when something will fail.
not always logical, but unfortunately, almost always true
… hence why this is just an idea/theory.