[PD] PD OOP?

[Mathieu Bouchard]

On Wed, 15 Dec 2010, brandon zeeb wrote:

> 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.

Oh ok. I couldn't imagine that people would cache mtof in a table.

You can send "reply-to $0-callback" to [s mtof] and see whether your [r 
$0-callback] gets a bang. If it does, it's because there's a [r mtof] that 
sees that and has a [t b s]=[s] to send you back a bang. This thing is in 
an instance of the mtof-cache abstraction somewhere. If you don't get the 
reply, then you dynamically open the mtof-cache as a toplevel patch (so 
that the cache doesn't disappear when you close the patch that created it) 
and you auto-hide it using "vis 0"-[s $0-canvas] [namecanvas $0-canvas].
Does that sound good ?

> In a given abstraction you do NOT have control of the order in which 
> your abstractions are created in memory.

Yes you do. It's the implicit object numbering. You can renumber an object 
by deleting and undeleting it. Any new object is created at the end of the 
order, such that when you save the patch, it will be reloadable in that 
order.

That said, it's considered bad practice to rely on this. People who need 
to rely on this may use dynamic patching instead.

> This is almost similar to prototypal inheritance where the instantiated 
> object controls the resource, not the prototype.

Uh, what do you mean here ? It doesn't match my knowledge of prototype 
inheritance (the SELF language).

> IMHO, directing your criticism at pd-vanilla alone is extremely 
> unproductive.

Please use ">" to indicate text that you are quoting from me. Normally, 
email programmes have at least an option for this, when it's not the 
default, or plain mandatory.

> I care more about Pd as a language and as a means to learn. For my 
> purposes, using externals is pointless,

I beg your pardon ???

Pd with a lot of externals is a language too !

> although I do appreciate all the hard work.

do you, really ?

> 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.

You could open the patch using [textfile], single out all [inlet] and 
[outlet], and sort them by $1 (x-position). But it doesn't work for 
non-abstractions (e.g. if I put lop~ as an argument to an abstraction...)

> With a bit of introspection, one could determine the name of the inlet,

inlets shouldn't be named using their $1, because [inlet~] uses $1 for a 
wholly different purpose.

>> Please first give an example of a useful use of the FlyweightPattern.
> Any given abstraction that requires a large lookup table

Actually, I only said that because I didn't realise that you were talking 
about a lookup-table made of [mtof] values, and not just [mtof].

> That would be great.  In my uses I don't really need a [unpack a a a],

In the end I called it [unpack e e e], because "a" means "any message", 
and if we're to completely share the same abbreviations for that and [t], 
"a" means a message of any length with any selector (header), whereas the 
"e" that I introduced stood for either f or s or p, but not b nor l nor a, 
because "e" stands for what you can get by saying "$1" or "$2" for example 
(one argument at a time).

> Basically, an abstraction (or object) is given what it needs to function 
> by a 3rd party.

Ok, then connections are given to the abstractions in a kind of attribute 
that we call an "outlet" : wouldn't that be a form of IoC ?

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC