Single-threaded processing is generally a host limitation, not a limitation of the plugin’s implementation. No plugin formats that I’m aware of except for CLAP support multi-threaded rendering, and even then that’s only possible if the DAW implements CLAP’s multithreading model.
EDIT: This of course doesn’t limit the possibility of the audio graph being multithreaded, but it’s a big enough lift that I don’t know if it’d be done in any reasonable amount of time for you to use it.
If you have an algorithm that would benefit from multithreading (and beware; the construction/teardown of threads can be expensive enough to make this impractical), you could implement your own multithreaded implementation. I’d recommend using a threadpool for this. In pseudocode:
// In your plugin's main processBlock
// Assume some functions expensiveAudioTask* exist and contain high-cost DSP
tp = Threadpool()
t1 = tp.start(expensiveAudioTask1);
t2 = tp.start(expensiveAudioTask2);
t3 = tp.start(expensiveAudioTask3);
// Do some other work on the main audio thread here
t1.join()
t2.join()
t3.join()
I’ve never attempted to multithread my DSP and would be hesitant to do so. You’d need multiple highly expensive jobs for it to be worth it IMO, and thread spawning can be a little too non-deterministic for realtime. That said, if your algorithm does consist of multiple expensive and fully parallel jobs, go for it. I’m sure it’ll be a fun project!
A quick search also yielded this discussion on the topic which you might find helpful.
EDIT: typo and information update.