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