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