<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Well there is [sendcanvas] in iemguts.<br><br>I'm not sure how related it is, but I sent Miller an idea (and maybe to this <br>list) about adding a glist field to [struct] and having a subpatch that is a <br>kind of template for that field. You could then define that structure as the <br>template for an array field in another struct so that, for example, glists <br>could be created and deleted simply by using [setsize].<br><br>Basically, think of a "Put" menu array, and each element is not just a float but <br>also an abstraction instance with the y-value as the amplitude for an <br>oscillator.<br><br>-Jonathan<br><br>--- On <b>Wed, 12/15/10, brandon zeeb <i><zeeb.brandon@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: brandon zeeb
<zeeb.brandon@gmail.com><br>Subject: Re: [PD] PD OOP?<br>To: "Jonathan Wilkes" <jancsika@yahoo.com><br>Cc: "PD List" <pd-list@iem.at><br>Date: Wednesday, December 15, 2010, 3:04 PM<br><br><div id="yiv1864934187">Many options have been proposed over the years, my favorite thus far is [thiscanvas]<br><a rel="nofollow" target="_blank" href="http://lists.puredata.info/pipermail/pd-dev/2004-12/003430.html">http://lists.puredata.info/pipermail/pd-dev/2004-12/003430.html</a><br>
<br><br><div class="yiv1864934187gmail_quote">On Wed, Dec 15, 2010 at 8:34 AM, Jonathan Wilkes <span dir="ltr"><<a rel="nofollow" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="/mc/compose?to=jancsika@yahoo.com">jancsika@yahoo.com</a>></span> wrote:<br><blockquote class="yiv1864934187gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font: inherit;" valign="top">What exactly would "this" (#4) look like in Pd?<br><br>-Jonathan<br><br>--- On <b>Wed, 12/15/10, brandon zeeb <i><<a rel="nofollow" ymailto="mailto:zeeb.brandon@gmail.com" target="_blank" href="/mc/compose?to=zeeb.brandon@gmail.com">zeeb.brandon@gmail.com</a>></i></b> wrote:<br>
<blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: brandon zeeb <<a rel="nofollow" ymailto="mailto:zeeb.brandon@gmail.com" target="_blank" href="/mc/compose?to=zeeb.brandon@gmail.com">zeeb.brandon@gmail.com</a>><div class="yiv1864934187im">
<br>Subject: Re: [PD] PD OOP?<br></div>To: "PD List" <<a rel="nofollow" ymailto="mailto:pd-list@iem.at" target="_blank" href="/mc/compose?to=pd-list@iem.at">pd-list@iem.at</a>><br>Date: Wednesday, December 15, 2010, 1:51 PM<div><div></div><div class="yiv1864934187h5"><br><br>
<div>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:<br>
<ol><li>Everything is global</li><li>No control over abstraction (object) construction order and lifecycle</li><li>No introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!)</li>
<li>No concept of "this"</li><li>No interfaces or abstract abstractions (to control inlet patterns)</li><li>Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list])</li>
<li>and on and on</li></ol>In 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.<br>
<br>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).<br>
<br>In use:<br><br>[bypass~ some_process~ 330 1 3 9]<br><br>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~]<br>
<br>I've attached [bypass~] and it's dependencies, have fun!<br><br>~Brandon<br>
</div><br></div></div><div class="yiv1864934187im">-----Inline Attachment Follows-----<br><br><div>_______________________________________________<br><a rel="nofollow" target="_blank" href="http://mc/compose?to=Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a rel="nofollow" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br></div></div></blockquote></td></tr></tbody></table><br>
</blockquote></div><br><br clear="all"><br>-- <br><font style="font-family: garamond,serif;" size="2"><span style="color: rgb(102, 102, 102);">Brandon Zeeb</span><br style="color: rgb(192, 192, 192);"></font><br><br>
</div></blockquote></td></tr></table><br>