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