Just wondering how cpu intensive the samplerate~ object is?
Is it just receiving from a value inside of pd, or does it need to retrieve directly from hardware every time?
We've been running into issues with [loadbang] to samplerate~ and having the rate change after our loadbangs, so were considering using [bang~].
Would that be reasonable, even if we might have to do it a few hundred times?
Hm, afaik [loadbang] only queries and outputs the samplerate itself when banged (I don't know what happens in the underlying C code though). Now in my understanding querying it once with loadbang should definitely use less CPU than querying it every blocksize (64 audio samples) with [bang~]... Could it be that your [samplerate]s are loadbanged before DSP is switched on? Getting the (message) order of loadbangs right can be tricky. For debugging: Perhaps try querying all [loadbangs] via a receive object after DSP has been switched on possibly using the [r pd-dsp-started] way described in its help patch?
If your rate changes after DSP has been switched on, could you compare your rate settings in the "Audio Settings..." menu entry before and after DSP is turned on? How/when does that setting there match the hardware sample rate? How is the hardware sample rate set? On the hardware itself (some switch), with a separate software utility, are you running the jack sound server, etc?