[PD] signal objects inside dynamically created abstractions?

Peter Plessas plessas at mur.at
Mon Aug 23 21:39:22 CEST 2010

Dear Matju, Roman,

thank you for your explanations which both make sense. I am just
wondering why the behavior is different in that:
Tilde objects added (dynamically) to a patch force a recompilation of
the dsp graph, while tilde objects inside dynamically created (loaded)
abstractions do not cause it.

best, P

On 08/21/2010 05:22 AM, Mathieu Bouchard wrote:
> On Sat, 21 Aug 2010, Peter Plessas wrote:
>> Just creating tilde objects inside a subpatch (without being contained
>> inside an abstractio) and connecting them works. I suppose there is a
>> reason for this, but didn't find it.
> Because the DSP is compiled, to save CPU time and SRAM space (that is,
> space in the fast RAM that accelerates the regular RAM).
> Then there is no incremental recompilation of the DSP, therefore, if it
> were a simple automatic recompilation, anytime there is a ~ object, it
> would recompile the whole thing, so, when you want to add many of them,
> it'd be very slow.
> There would be a fast automatic way, involving a [delay 0] (that is,
> clock_delay(,0)) every time you add a tilde object, such that if you add
> several objects within a [until], [repeat], [foreach], or [list-drip],
> it only recompiles once. But Pd doesn't do this.
> Instead you are responsible for doing it. It wouldn't be so bad, if you
> had actually access to whether the DSP is currently On, because else you
> can "turn back On" a DSP that never was. If you listen to [r pd], you
> only know about new On/Off switches, not the state when your abstraction
> was created. We'd need an extra external for that (if it does not exist
> yet...).
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

More information about the Pd-list mailing list