<span style="color: rgb(102, 102, 102);">#7: and on and on 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</span><br><br>Say you compute a raised cosine window and store it in a table, this table is used within one instance of a granular table reading voice abstraction, 1-n of these abstractions are created at run time for polyphony. Now you have N instances of this table. Some people cache mtof in a table, and thus that was my original point.<br>
<br><span style="color: rgb(102, 102, 102);">2. No control over abstraction (object) construction order and lifecycle</span><br><br>In a given abstraction you do NOT have control of the order in which your abstractions are created in memory. With my attempt at the Flyweight pattern for large lookup tables, it became apparent that if I were to remove an abstraction while editing a patch, I would have no idea if I removed the abstraction with reference to the real table or not. This is almost similar to prototypal inheritance where the instantiated object controls the resource, not the prototype. For example, a given UI on an Android phone widget will usually share graphic resources with others of it's type to save memory.<br>
<br>
<span style="color: rgb(102, 102, 102);">IMHO, directing your criticism at pd-vanilla alone is extremely
unproductive. You have to accept the fact that doing real work in Pd may
require a lot of externals. It's sad, but it's like that. I wouldn't
use Pd if it didn't have externals.</span><br><br>I care more about Pd as a language and as a means to learn. For my purposes, using externals is pointless, although I do appreciate all the hard work.<br><br><span style="color: rgb(102, 102, 102);">#5. No interfaces or abstract abstractions (to control inlet patterns)</span><br>
<br>I would like to know which inlets of a given abstraction are signals and which are events for the purpose of dynamic patching / autowiring. Bonus points if inlet metadata is available.<br><br>With a bit of introspection, one could determine the name of the inlet, and thus autowire (dynamically patch) it to the correct binding (binding in my library, u_dispatch in RjDj). I work around this by enforcing a strict interface (as with RjDj) of two event inlets (hot and cold) where the cold inlet receives binding (dispatch) events. ~ objects just prepend signal inlets to the hot-side.<br>
<br>
<span style="color: rgb(102, 102, 102);">Please first give an example of a useful use of the FlyweightPattern.</span><br><br>Any given abstraction that requires a large lookup table obtains a reference (ie: the table name) of this large table without having to construct it by itself, it doesn't know how to create it, it just receives it... but every abstraction that requires this table receives the same one. This is much like a singleton. Otherwise it's a complete waste of resources.<br>
<br style="color: rgb(102, 102, 102);"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; color: rgb(102, 102, 102);">
6. Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list])<br>
</blockquote>
<br style="color: rgb(102, 102, 102);"><span style="color: rgb(102, 102, 102);">
I once proposed alternate versions of [unpack], [select], etc., that had
no type restrictions. There was a discussion on it. See :</span><br><br>That would be great. In my uses I don't really need a [unpack a a a], usually by the time I reach a [pack] I already have a strong enough determination of what types I'm working with (my binding/dispatch is type-agnostic though), but it would be nice.<br>
<br><span style="color: rgb(102, 102, 102);">Is this just ONE kind of InversionOfControl (IoC) ? I'd guess that there
are several quite different manners of doing that in Pd, no ? But I
have trouble reading definitions and tutorials of IoC. I probably have
used a bunch of different IoC techniques in Pd and other languages
already.</span><br><br>Basically, an abstraction (or object) is given what it needs to function by a 3rd party. The abstraction in question only focuses on it's given task and doesn't know how to create it's dependencies. For testability and reusability, this is a fantastic pattern. So far I've been using constructor IoC (in creation arguments), but one could just as easily pass this information as a list to an abstraction's inlet. Max's [poly] and RjDj's u_makepoly~ objects are a very simple example of this.<br>
<br>If you look at the structure of any given synthesizer voice in Pd, I'm sure you can think of other useful examples of this.<br><br>Cheers,<br>~Brandon<br><br><br><div class="gmail_quote">On Wed, Dec 15, 2010 at 10:23 AM, Mathieu Bouchard <span dir="ltr"><<a href="mailto:matju@artengine.ca">matju@artengine.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Wed, 15 Dec 2010, brandon zeeb wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. No control over abstraction (object) construction order and lifecycle<br>
</blockquote>
<br>
What's that ?<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3. No introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!)<br>
</blockquote>
<br>
Why do you don't care about externals that might do the job ???<br>
<br>
IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. You have to accept the fact that doing real work in Pd may require a lot of externals. It's sad, but it's like that. I wouldn't use Pd if it didn't have externals.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
5. No interfaces or abstract abstractions (to control inlet patterns)<br>
</blockquote>
<br>
Strictly speaking, interfaces, or completely abstract classes, need only be made explicit in languages that have strict method-lookup. In languages like Python/Ruby/Perl/Tcl/ObjC/etc., all the lookup is at run time, and likewise for PureData. In those languages, there is usually no built-in way to declare interfaces, because the method-lookup wouldn't use those declarations anyway.<br>
<br>
Strict method-lookup normally means that "anything-methods" don't exist, and that means that complicated workarounds have to be provided instead of solutions that depend on "anything-methods" and loose method-lookup.<br>
<br>
I would like to know what you mean by "inlet patterns" here.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
6. Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list])<br>
</blockquote>
<br>
I once proposed alternate versions of [unpack], [select], etc., that had no type restrictions. There was a discussion on it. See :<br>
<br>
<a href="http://www.mail-archive.com/pd-list@iem.at/msg08636.html" target="_blank">http://www.mail-archive.com/pd-list@iem.at/msg08636.html</a><br>
<a href="http://www.mail-archive.com/pd-list@iem.at/msg08644.html" target="_blank">http://www.mail-archive.com/pd-list@iem.at/msg08644.html</a><br>
but also the rest of the thread...<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
7. and on and on 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,<br>
</blockquote>
<br>
[mtof] does not use a lookup-table :<br>
<br>
t_float mtof(t_float f) {<br>
if (f <= -1500) return 0;<br>
if (f > 1499) return mtof(1499);<br>
return 8.17579891564 * exp(.0577622650 * f);<br>
}<br>
void mtof_float(t_object *x, t_float f) {<br>
outlet_float(x->ob_outlet, mtof(f));<div class="im"><br>
}<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
one can attempt the Flyweight pattern.<br>
</blockquote>
<br></div>
Please first give an example of a useful use of the FlyweightPattern.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
[bypass~ some_process~ 330 1 3 9]<br>
</blockquote>
<br></div>
Is this just ONE kind of InversionOfControl (IoC) ? I'd guess that there are several quite different manners of doing that in Pd, no ? But I have trouble reading definitions and tutorials of IoC. I probably have used a bunch of different IoC techniques in Pd and other languages already.<br>
<br>
I mean that even simple patches without any abstractions would use implicitly IoC in some manner.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction.<br>
</blockquote>
<br></div>
If you used externals, you could make the number of arguments to be variable and unlimited. You could also make it lookup the abstraction in the parent's folder, so that I can put some_process~.pd in the same folder as the main patch, for example.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced.<br>
</blockquote>
<br></div>
It's enforced at run time. There's also nothing wrong to having more than 2 inlets in this case, as long as you wouldn't be using the extra inlets in that case anyway (or can do without them).<div><div></div>
<div class="h5"><br>
<br>
_______________________________________________________________________<br>
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC</div></div></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>