I think some of the confusion here is around what the thread we’re talking about does – it’s the message thread. It exists whether or not there are editors attached to a processor. When an editor is open, it does call the drawing methods for it, but it exists with or without an editor.
In fact, whether the code is in the editor or processor classes is entirely unrelated to what thread it’s called in – you can have a processor method called from the editor on the Message thread, or an editor method called from the audio thread (although you should be careful going this direction).
If you put a method in your processor which loads the audio you need, you can call that method from anywhere which is executed on the message thread. In practice, as long as the method isn’t called from ProcessBlock() or any method called by it you’re probably fine.
For switching presets or audio files, or for loading state – all things which can be expected to take some time – in many cases it is appropriate to use the AudioProcessor::suspendProcessing(bool) method to ensure that the operation doesn’t cause glitches on the processing callback. If you want to arbitrarily load a file from the message thread, you have a lot of options. juce::Timer regularly calls a virtual method on the message thread (derive your processor from Timer and implement the callback), as do calls to ActionListener::actionListenerCallback and ChangeListener::changeListenerCallback.