[PD] samplerate~

[Peter P.]

* Matt Davey <hard.off at gmail.com> [2020-02-18 09:35]:
> 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?