On 2/18/20 8:43 AM, Matt Davey wrote:
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?
[samplerate~] reports the internal samplerate of the Pd process, and trusts that the hardware and Pd agree on that (this is mostly the case, but sometimes not; e.g. when a hardware/audio-API doesn't support the requested samplerate and fails to report that back).
We've been running into issues with [loadbang] to samplerate~ and having the rate change after our loadbangs, so were considering using [bang~].
[samplerate~] also tries to take resampling into account (as defined with [block~]) i could imagine some glitches at loadbang time if you have a weird (that involves changing the block-setup with [block~] resp [switch~])
remember, that a [loadbang] in a child-patch fires after a [loadbang] in the parent patch (this is by design). if you have a child-patch that uses [loadbang] to query [samplerate~], and in a parent-patch you use another [loadbang] to change the re-sampling, then the re-sampling will change *after* you have queried the samplerate.
Would that be reasonable, even if we might have to do it a few hundred times?
this seems like overkill. you could try to call [samplerate~] whenever the DSP is turned on. something like:
[r pd] | [route dsp] | | [loadbang] |/ [bang( | [samplerate~] | [change] |
gfmdsar IOhannes