[PD] samplerate~

[IOhannes m zmölnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200218/00fbc831/attachment.sig>