Currently the plugin scanning procedures, as well as it's internal states, are stored and processed in RecursionTestAudioProcessor. This is very bad practice as the processor, of course, should only focus on audio processing things.
The new separate class should include:
[ ] scanning plugins
[ ] Scan VST2 and others
[ ] Support scanning on all platforms (currently the path only supports Windows)
[ ] handling errors
[ ] store them into list
[ ] serializing/deserialization (#22)
Juce and it's example project AudioPluginHost has things worth looking into it:
juce::KnownPluginList (we are already using it in RecursionTestAudioProcessor)
juce::KnownPluginList::CustomScanner
juce::AudioPluginFormat
juce::AudioUnitPluginFormat for scan independently of OS (need verification)
Currently the plugin scanning procedures, as well as it's internal states, are stored and processed in
RecursionTestAudioProcessor. This is very bad practice as the processor, of course, should only focus on audio processing things. The new separate class should include:Juce and it's example project
AudioPluginHosthas things worth looking into it:juce::KnownPluginList(we are already using it inRecursionTestAudioProcessor)juce::KnownPluginList::CustomScannerjuce::AudioPluginFormatjuce::AudioUnitPluginFormatfor scan independently of OS (need verification)