When should I be managing my own threads in a JUCE app?

I’m taking an OS class and we did a few threading examples in C, but I feel like JUCE already handles this for me. What good was learning how threading works if I’m not actually doing it myself?

Audio and Main (GUI/messages) threads alrea already managed by Juce. You should only do audio stuff and light GUI/comunication there respectively. If you need to do something heavier like a file loading, “heavy” operations for some specific visuals (i.e FFT for a spectrum visualization), then that’s the right time to use extra threads.

You have examples of the file loading thing in Juce tutorials

IMHO it is important to know how thread work and behave in relation to each other even if you are not actively spawning threads of your own for background tasks

I would differentiate between jobs like loading (data/samples), which should happen asynchronously, and background threads like pre-buffering, analyser for visual, or other continuous jobs.

The other differentiation: in plugins I would avoid parallel audio processing, because there are other plugins active at the same time, so the host is suited best to maximise the power of all cores. Which answers the other question: for an application parallelising can give good results. E.g. when writing a host process each track in parallel can be a good idea.

But like others said before, the already existing setup of MessageManager for low priority and the audio thread run by the driver or the host is perfect for most use cases.

1 Like