<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">remember, that a [loadbang] in a child-patch fires after a [loadbang] in
the parent patch (this is by design).</pre>
</blockquote>
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.</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">you could try to call [samplerate~] whenever the DSP is turned on.
something like:
[r pd]
|
[route dsp]
|
| [loadbang]
|/
[bang(
|
[samplerate~]
|
[change]
|
</pre>
</blockquote>
</p>
<p>Even better:</p>
<pre class="moz-quote-pre" wrap="">[r pd-dsp-started]
|
| [loadbang]
|/
[bang(
|
[samplerate~]
|
[change]
|
</pre>
<p>"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].</p>
<p>"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~]" *)<br>
</p>
<p>Christof</p>
<p>*) 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.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 18.02.2020 10:30, IOhannes m zmölnig
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8d70a99a-1868-42fb-dd91-19a0fd554992@iem.at">
<pre class="moz-quote-pre" wrap="">On 2/18/20 8:43 AM, Matt Davey wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
[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).
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
We've been running into issues with [loadbang] to samplerate~ and having
the rate change after our loadbangs, so were considering using [bang~].
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
[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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Would that be reasonable, even if we might have to do it a few
hundred times?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</body>
</html>