Do you get presets from disc when the Editor initializes (into a data structure vector), or do you do that in PluginProcessor.cpp on initialization? And keep the list of presets in a member variable vector in PluginProcessor?
Do you use a different thread to get presets to ensure loading time is not slowed?
(I have a cycle through presets back and forward on my GUI)
If I understand correctly, I found the second more convenient.
Maybe related/relevant: I had my Processor create a ComboBox and assign values, but the Editor does the layout. The value tree (in the Processor) holds/saves/restores just the combo selection index. The Processor needs to translate this even if no Editor has existed yet.
I had found this tricky, but I’m fairly new in Juce.
Your plugin processor needs to be able to exist independently of your plugin editor window. The host might then control it via the parameters, for example. So, thinking of the plugin processor as the plugin itself and the editor as just a window, I would definitely find myself storing most things in the processor. The editor can always access the processor but the editor is not guaranteed to exist when the processor looks for it.
As for threads, I would leave that to the experts to answer conclusively but my instinct would be to do it on the message thread unless the files are really large.
So you’d lean towards storing a vector of presets (preset name string, preset path) in PluginProcessor and manipulating that from PluginEditor.
The preset files are only small XML files, so in theory should be quick… but I know disc access is probably the slowest task you can perform.
I am already checking for the existence of my preset folder etc. in PluginProcessor anyway, so that seems good.
Having it on another thread seems attractive because it would speed up plugin load, but might that provoke crashes on certain platforms? Hopefully someone can chime in.
I will reiterate the idea that your editor is simply a view into the plugin. The functionality should all live in the processor. As unlikely as it is, a good thing to consider is how would it work if two editors were open to the same plugin instance?
@cpr2323 can that happen?! I have never considered that!
@TrustedSteed Yes, I’d definitely store anything not ‘GUI-only’ in the processor.
Also, in case there is any confusion, I would state that not every function in your processor will be run on the real time thread. As for the background thread idea, if it is a performance question and you are not sure then people will tell you to test/measure it and see. In this case I would agree with the standard advice of “write it simply and safely, get it working well and worry about performance later.”
I don’t know. 
But it’s an approach I use for thinking about editor/processor separation. A quick search seems to indicate no for vst2, I didn’t quickly find anything about VST3, and I didn’t bother looking up the others.
I’d suggest that even most GUI-only things might need to be stored in the processor, in order to be able to restore the Editor in the same state it was in if you close the Editor and re-open it. If the Editor gets destroyed when you close it, then you will lose any UI settings you had if you close and re-open it. Storing that information in the Processor will keep that information alive even if the Editor is not currently shown.
I want to further comment that this design perspective has influenced how I write all software, not just plugins. Ie. The UI is always a view into the underlying systems. And with JUCE based software, I use ValueTrees for the underlying data models, wherever possible.
