Re: [PD] signal objects inside dynamically created abstractions?
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
Re: [PD] signal objects inside dynamically created abstractions?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal objects inside dynamically created abstractions?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal objects inside dynamically created abstractions?
Hi, On Sat, Aug 21, 2010 at 12:00:38AM +0200, Peter Plessas wrote: Pd's dsp is switched on. Creating an abstraction inside a subpatch by internal pd messages like [obj 10 10 abstraction The tilde objects inside this abstraction do not work unless Pd's dsp is toggled (off and on again). If I do bigger dsp object generation, I generally turn off dsp before creating objects, then create all objects, then switch it on again. It seems object creation is faster with DSP off anyway. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal objects inside dynamically created abstractions?
On Sat, 2010-08-21 at 00:00 +0200, Peter Plessas wrote: Dear list, wondering about the following behavior: Pd's dsp is switched on. Creating an abstraction inside a subpatch by internal pd messages like [obj 10 10 abstraction The tilde objects inside this abstraction do not work unless Pd's dsp is toggled (off and on again). 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. When creating more than one object in 0 logical time dynamically, I'd recommend to first turn dsp off, create the objects, turn dsp on again. When doing this, all tilde objects are working afterwards. Also this approach turns out to be a _lot_ faster than with dsp turned on during creation. I suppose this because with dsp turned on, the dsp graph is recompiled on every creation, while with dsp turned off it is only recompiled once, when turning dsp on. Can someone with knowledge of the C code confirm this? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] signal objects inside dynamically created abstractions?
Dear list, wondering about the following behavior: Pd's dsp is switched on. Creating an abstraction inside a subpatch by internal pd messages like [obj 10 10 abstraction The tilde objects inside this abstraction do not work unless Pd's dsp is toggled (off and on again). 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. P. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] signal objects inside dynamically created abstractions?
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
