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?
- Matt Davey hard.off@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?
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
- IOhannes m zmölnig zmoelnig@iem.at [2020-02-18 10:30]:
[...]
remember, that a [loadbang] in a child-patch fires after a [loadbang] in the parent patch (this is by design).
Does "child-patch" mean subpatches as well as abstractions?
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.
I can't seem to understand the logic of the sequence of the three loadbangs in this example. Why would "another" loadbang in the parent patch fire after the one in the child-patch?
thanks! P
On 2/18/20 11:56 AM, Peter P. wrote:
- IOhannes m zmölnig zmoelnig@iem.at [2020-02-18 10:30]:
[...]
remember, that a [loadbang] in a child-patch fires after a [loadbang] in the parent patch (this is by design).
Does "child-patch" mean subpatches as well as abstractions?
yes.
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.
I can't seem to understand the logic of the sequence of the three loadbangs in this example. Why would "another" loadbang in the parent patch fire after the one in the child-patch?
i only count two [loadbang]s.
once the patch is built, the loadbangs start to fire. first, the [loadbang] in the child-patch fires, querying [samplerate~] and outputting something like 44100. then, the [loadbang] in the parent-patch fires, sending something like [set 1024 1 2( to [block~], thus upsampling the entire parent-patch (including the child-patch) by a factor of 2.
the actual samplerate (of both parent- and child-patch) is now 88200, but [samplerate~] has already reported 44100.
gsdmr IOhannes
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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2/18/20 3:47 PM, Christof Ressi wrote:
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.
doh, thanks a lot.
The bug/feature with [r pd-dsp-started] is that you'll get a bang every time you save the patch, so it's not very useful while patching I'd say
On Tue, Feb 18, 2020 at 3:00 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 2/18/20 3:47 PM, Christof Ressi wrote:
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.
doh, thanks a lot.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2/18/20 10:21 PM, ffdd cchh wrote:
The bug/feature with [r pd-dsp-started] is that you'll get a bang every time you save the patch,
it's neither a bug nor a feature. the DSP-graph is re-built when the patch is saved, and so the "pd-dsp-started" is emitted.
so it's not very useful while patching
how so?
(a [metro] will also send bangs while patching, and yet it is useful in live-coding contexts.)
gmsdtr IOhannes
- IOhannes m zmölnig zmoelnig@iem.at [2020-02-18 23:28]:
On 2/18/20 10:21 PM, ffdd cchh wrote:
The bug/feature with [r pd-dsp-started] is that you'll get a bang every time you save the patch,
it's neither a bug nor a feature. the DSP-graph is re-built when the patch is saved, and so the "pd-dsp-started" is emitted.
so it's not very useful while patching
how so?
(a [metro] will also send bangs while patching, and yet it is useful in live-coding contexts.)
After a moment of thinking about this, and about the bug with [bang~] only working after creation when the dsp graph is rebuilt, I must admit I do find it awkward that certain things in a pd dsp graph only work after explicitely forcing the dsp grap to be rebuilt by saving the patch. After all, would anyone be happy with a message object that only works correctly after having saved a patch? There might be implementations details I am ignorant of, which prevent other behavior, but as a Pd user this usefulness does come to certain minds.
looking up for further discussion, P
about the bug with [bang~] only working after creation when the dsp graph is rebuilt
Yes, it's quite a long-standing bug and I agree this should be fixed. The problem is that Pd only updates the DSP graph when you connect the signal inlet/outlet of a DSP object, not when you create it. You can also observe this bug with [env~], for example: create a new [env~] object and connect the message outlet to a [print] - it won't print anything because no signal inlet/outlet was involved. Now toggle DSP and it will start printing.
This could be fixed easily inside "canvas_obj()". I might do a PR.
Christof
On 18.02.2020 23:53, Peter P. wrote:
- IOhannes m zmölnig zmoelnig@iem.at [2020-02-18 23:28]:
On 2/18/20 10:21 PM, ffdd cchh wrote:
The bug/feature with [r pd-dsp-started] is that you'll get a bang every time you save the patch,
it's neither a bug nor a feature. the DSP-graph is re-built when the patch is saved, and so the "pd-dsp-started" is emitted.
so it's not very useful while patching
how so?
(a [metro] will also send bangs while patching, and yet it is useful in live-coding contexts.)
After a moment of thinking about this, and about the bug with [bang~] only working after creation when the dsp graph is rebuilt, I must admit I do find it awkward that certain things in a pd dsp graph only work after explicitely forcing the dsp grap to be rebuilt by saving the patch. After all, would anyone be happy with a message object that only works correctly after having saved a patch? There might be implementations details I am ignorant of, which prevent other behavior, but as a Pd user this usefulness does come to certain minds.
looking up for further discussion, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
It depends. If DSP is on, you get a bang. If it's off, you won't.
So, If I am expecting a bang because I saved and DSP is off, it just bugs me that no bang is sent :)
If, say, you want to send one and only one bang to [switch~] so as to graph tables when DSP starts, then [r pd-dsp-started] is only useful if you spigot-out future bangs/saves/etc, otherwise you are graphing tables on every save...
It's a feature if you use it for randomness, say, to randomize seeds according to when dsp on/off switching or graph redrawing falls, say linked with a [timer] object :)
Perhaps [r pd-dsp-started] should only send bangs when dsp starts or stops, and not when the dsp graph is redrawn.
In any case, I think it's the misnomer what's confusing me. I realize that saving redraws the dsp graph, but I don't see why the dsp would "start" if it was already switched "on", even though I do understand that, for a tiny moment, the dsp needs to be off behind the scenes.
On Tue, Feb 18, 2020 at 5:30 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
On 2/18/20 10:21 PM, ffdd cchh wrote:
The bug/feature with [r pd-dsp-started] is that you'll get a bang every time you save the patch,
it's neither a bug nor a feature. the DSP-graph is re-built when the patch is saved, and so the "pd-dsp-started" is emitted.
so it's not very useful while patching
how so?
(a [metro] will also send bangs while patching, and yet it is useful in live-coding contexts.)
gmsdtr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
If DSP is on, you get a bang. If it's off, you won't.
Yes, that's pretty much expected, I guess. After all, it's not [savebang] ;-)
Perhaps [r pd-dsp-started] should only send bangs when dsp starts or stops, and not when the dsp graph is redrawn.
When the DSP graph gets rebuilt, DSP *does* stop and start (again).
even though I do understand that, for a tiny moment, the dsp needs to be off behind the scenes
It doesn't matter how much time passes between stopping and starting DSP, the point is that the DSP graph has or might have changed and "pd-dsp-started" will report it.
If, say, you want to send one and only one bang to [switch~] so as to graph tables when DSP starts
What do you consider a "real" start of DSP?
Actually, I'm rather asking myself whether it's necessary that saving triggers a rebuilt of the DSP graph...
Christof
On 18.02.2020 23:57, ffdd cchh wrote:
It depends. If DSP is on, you get a bang. If it's off, you won't.
So, If I am expecting a bang because I saved and DSP is off, it just bugs me that no bang is sent :)
If, say, you want to send one and only one bang to [switch~] so as to graph tables when DSP starts, then [r pd-dsp-started] is only useful if you spigot-out future bangs/saves/etc, otherwise you are graphing tables on every save...
It's a feature if you use it for randomness, say, to randomize seeds according to when dsp on/off switching or graph redrawing falls, say linked with a [timer] object :)
Perhaps [r pd-dsp-started] should only send bangs when dsp starts or stops, and not when the dsp graph is redrawn.
In any case, I think it's the misnomer what's confusing me. I realize that saving redraws the dsp graph, but I don't see why the dsp would "start" if it was already switched "on", even though I do understand that, for a tiny moment, the dsp needs to be off behind the scenes.
On Tue, Feb 18, 2020 at 5:30 PM IOhannes m zmölnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
On 2/18/20 10:21 PM, ffdd cchh wrote: > The bug/feature with [r pd-dsp-started] is that you'll get a bang > every time you save the patch, it's neither a bug nor a feature. the DSP-graph is re-built when the patch is saved, and so the "pd-dsp-started" is emitted. > so it's not very useful while patching how so? (a [metro] will also send bangs while patching, and yet it is useful in live-coding contexts.) gmsdtr IOhannes _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list-- fdch.github.io http://fdch.github.io
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
What do you consider a "real" start of DSP?
Toggle DSP button ON, aka: ";pd dsp 1"
Actually, I'm rather asking myself whether it's necessary that saving triggers a rebuilt of the DSP graph...
I believe connections need to be re-asserted/ordered so as to re-draw the graph. Same thing happens with non-tilde objects on canvas.
To add to your question: if no tilde object was touched/moved (or even exists on a patch) why would the dsp graph be rebuilt on save?
Toggle DSP button ON, aka: ";pd dsp 1"
Then just catch "pd dsp 1"?
Anyway, technically, all those cases are the same: DSP stops, the DSP graph is rebuilt, DSP continues.
I think your specific use case is not so much about the fact that DSP has started, but more about that the *user* has started DSP.
Christof
On 19.02.2020 00:21, ffdd cchh wrote:
What do you consider a "real" start of DSP?
Toggle DSP button ON, aka: ";pd dsp 1"
Actually, I'm rather asking myself whether it's necessary that saving triggers a rebuilt of the DSP graph...
I believe connections need to be re-asserted/ordered so as to re-draw the graph. Same thing happens with non-tilde objects on canvas.
To add to your question: if no tilde object was touched/moved (or even exists on a patch) why would the dsp graph be rebuilt on save?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
ffdd cchh -
IOhannes m zmölnig -
Matt Davey -
Peter P.