[PD] samplerate~

[Christof Ressi]

> remember, that a [loadbang] in a child-patch fires after a [loadbang] in
> the parent patch (this is by design).
It's really the other way around. I know it's just a typo, I just wanted 
to point it out for the people following this thread.

> you could try to call [samplerate~] whenever the DSP is turned on.
> something like:
>
> [r pd]
> |
> [route dsp]
> |
> | [loadbang]
> |/
> [bang(
> |
> [samplerate~]
> |
> [change]
> |

Even better:

[r pd-dsp-started]
|
| [loadbang]
|/
[bang(
|
[samplerate~]
|
[change]
|

"pd dsp" is only sent when switching DSP on *manually*, but Pd will 
always send a bang to "pd-dsp-started" whenever the DSP state changes 
(e.g. by messaging the [block~] object). If you only use the samplerate 
value in DSP calculations, you can even omit the [loadbang].

"pd-dsp-started" / "pd-dsp-stopped" is a rather recent addition (maybe 
Pd 0.49? I'm not sure). It is also very useful to prevent the "angry 
[vline~]" *)

Christof

*) When you send messages to the [vline~] object without DSP running, 
they will gradually pile up and eventually eat all your CPU. 
"pd-dsp-started"/"pd-dsp-stopped" + [spigot] help to prevent this.


On 18.02.2020 10:30, IOhannes m zmölnig wrote:
> 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
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200218/4438a99a/attachment-0001.html>