AudioProcessor::wrapperType is not yet defined in the PluginProcessor’s constructor: indeed, it is defined by wrappers after the various createPluginFilter’s returns.
However, it can be needed to be able to get this information in the constructor.
I propose that the wrapper type be given as a createPluginFilter() parameter, as a PluginProcessor’s constructor’s parameter, then passed to the AudioProcessor’s constructor (diff attached).
This is quite a heavy change (user code needs update), which can be avoided using the alternative to store the wrapperType in a thread-specific (ThreadLocalValue?) variable during the AudioProcessor’s construction, but this can be quite dangerous (recursive AudioProcessor construction, for instance, requiring to restore previous stored wrapperType value at end of scope…).
All the best and thanks for all the juce.
PS: here is the patch, the forum did not accept .diff nor .patch
Agreed, I’m also using a similar trick, with a “createPluginFilterWithFormat(const String &wrapper_type)” function instead of “createPluginFilter()”
(using a String wrapper_type argument also allows new wrappers not yet handled by juce, such as lv2 plugins or whatever, without having to edit the juce::WrapperType enum).
Yikes… That’d mean that everyone would suddenly be faced with confusing compile errors, and would have to figure out what’s going on, then figure out how to update their code, all the while cursing me…
I’d obviously have preferred to do it this way too, but it’d cause a lot of hassle to add now. Surely there’s another way… Perhaps set up a thread-local before construction that the base class constructor can use to initialise itself?
