Just would like to point out to anybody else (assuming they are thinking of AU/AUv3) - in that example Chris you created your own parallel thread workgroup that you join/leave for every thread loop (for threads that would run asynchronously to the device i/o thread), so it may improve thread synchronization/prioritization but not necessarily in sync with the hardware/plugin callback.
For AU (JUCE wrapper) specifically, I learnt from others here that it is necessary to add a renderContextObserverCallback function that gets registered when GetProperty’ is called (I assume by the host/DAW) with the parameter ‘kAudioUnitProperty_RenderContextObserver’. The observer later gets called when the driver workgroup changes/is set (I guess part of the plugin launch sequence/any time the hardware device selection changes).
(
)
I’m not sure if AUv3 should use the same pattern - possibly it would be similar, sorry I didn’t get time to look through JUCE AUv3 wrapper. I know the JUCE team was looking into AUv3 requirements, but not sure if they made progress there in terms of audio workgroups.
(BTW, I think you are the same Chris I met at the SF developer meetup? 
)