Well there is [sendcanvas] in iemguts. I'm not sure how related it is, but I sent Miller an idea (and maybe to this list) about adding a glist field to [struct] and having a subpatch that is a kind of template for that field. You could then define that structure as the template for an array field in another struct so that, for example, glists could be created and deleted simply by using [setsize].
Basically, think of a "Put" menu array, and each element is not just a float but also an abstraction instance with the y-value as the amplitude for an oscillator. -Jonathan --- On Wed, 12/15/10, brandon zeeb <zeeb.bran...@gmail.com> wrote: From: brandon zeeb <zeeb.bran...@gmail.com> Subject: Re: [PD] PD OOP? To: "Jonathan Wilkes" <jancs...@yahoo.com> Cc: "PD List" <pd-list@iem.at> Date: Wednesday, December 15, 2010, 3:04 PM Many options have been proposed over the years, my favorite thus far is [thiscanvas] http://lists.puredata.info/pipermail/pd-dev/2004-12/003430.html On Wed, Dec 15, 2010 at 8:34 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote: What exactly would "this" (#4) look like in Pd? -Jonathan --- On Wed, 12/15/10, brandon zeeb <zeeb.bran...@gmail.com> wrote: From: brandon zeeb <zeeb.bran...@gmail.com> Subject: Re: [PD] PD OOP? To: "PD List" <pd-list@iem.at> Date: Wednesday, December 15, 2010, 1:51 PM In my experience with emulating OOP in Pd I've had moderate success. As a Java developer by day, I find myself attempting to recreate familiar patterns within Pd (ie: usually IoC and Flyweight in Pd). Main problems with recreating OOP in Pd are the following: Everything is globalNo control over abstraction (object) construction order and lifecycleNo introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!) No concept of "this"No interfaces or abstract abstractions (to control inlet patterns)Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list]) and on and onIn most Pd patches, I see people using a few lookup tables again and again (ie: mtof). As this is a complete waste of memory, one can attempt the Flyweight pattern. However, doing so in Pd is a very dangerous game, as you will have NO idea which abstraction first created the table and thus have no control over retaining access to it. In my library I've dropped this approach in favor of something closer to IoC. Basic IoC is very possible, and indeed very rewarding. Very often I pass in other abstractions as object creation arguments. The most simple example of this in my library is my [bypass~] abstraction used to dynamically enable and disable a given abstraction. I use this EVERYWHERE to save CPU cycles in combination with another object to programmatically disable the sub-abstraction when the user selects a given value (ie: when the filter cutoff is at MAX with no resonance, disable the filter). In use: [bypass~ some_process~ 330 1 3 9] Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction. Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced. [bypass~] passes it's 1st two inlets to the sub-abstraction, while the 3rd is used to control [bypass~] I've attached [bypass~] and it's dependencies, have fun! ~Brandon -----Inline Attachment Follows----- _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Brandon Zeeb
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
