Wouldn’t make it sense to move some general purpose classes for hosting plugins from the AudioPluginHost-folder into a new juce module? I guess a lot of people just use 1:1 copies of these classes for their own audio-plugin hosting code. Classes like PluginWindow contain platform specific fixes like GUI scaling etc…, so every plugin host could benefit from improves in these classes automatically.
PS: vice versa the Audio Plugin Host would benefit from other audio host developers experiences
What do you think of that?
This falls into the grey area between application code and the core API. Back when we released one of the 5.x versions of JUCE we decided that the AudioPluginHost was too complex to form part of the JUCE examples, so we moved it out into the extras directory and I still feel like its remit is a bit beyond what should be provided as part of JUCE.
Part of being a responsible library maintainer is to push back against requests to add lots of bits to the core API, despite it making us unpopular with the requestors. We may revisit this particular issue in the future, as it’s not a clear cut case, but for now we’ll leave the components of AudioPluginHost where they are.
okay! Thanks for the statement 
