Robin Schmidt
Robin Schmidt
the assert message is actually quite informative. apparently, the midi preset switch happens in the audio-thread (midi events are generally handled in the audio thread)...and that preset switch causes a...
ok - although i have no idea, how your hack works...what it has to do with current note...but anyway ...if it becomes more common to trigger events from the audio...
aaahhh - ok - i understand. i used the same mechanism before for parameters updating (and repainting) widgets, before i figured out how to do that via MessageManager::callAsync https://juce.com/doc/classMessageManager#ac3ed7c9a9885eba962cca454552b2902 it's...
but: what if there is no editor open? then the preset switch won't work, right?
try `MessageManager::callAsync( [this]{loadNextFile();} );` etc.
if that doesn't work, you can send the change-message from the module to itself, like i described above
actually, this looks right to me. could the problem be that you have a bool flag "loadNextFile" - with the same name as the function loadNextFile? i guess the compiler...
i've done this because i was considering to switch to use std::function also myself and maybe throw away my old stuff. it's highly unelegant to have these two alternative ways...
the most elegant solution would perhaps be indeed to templatize the Parameter class on the the callback type. then, i would also not have to have 3 different callback members...
this is not immediately urgent - it doesn't make or break any functionality, it's an optimization thing - but something, we may consider in the mid term