info at christofressi.com
Wed Feb 19 00:35:50 CET 2020
> 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.
On 18.02.2020 23:53, Peter P. wrote:
> * IOhannes m zmölnig <zmoelnig at 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,
> 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...
More information about the Pd-list