Thank you! Peter
On 08/23/2010 09:46 PM, Miller Puckette wrote:
Main difference is that Pd wasn't designed with self-editing patches in mind; sending canvases directly to 'edit' them is effectively relying on Pd's internal mechanisms which aren't designed as a user interface.
cheers Miller
On Mon, Aug 23, 2010 at 09:39:22PM +0200, Peter Plessas wrote:
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list