Well, maybe not orthogonal depending on how it's done. I've been thinking for
10 years about allowing patches to cache a store of dependencies in the form
of abstractions associated with names that can then be called by name. The same mechanism could: 1) allow you to say "clone osc~" by creating an anonymous patch that just has an osc~ and inlets/outlets; 2) allow "clone -" or something that would allow you to edit the clonee on the fly (this is Dan's idea, which hadn't occirred to me yet) 3) allow you to publish in a single ".pd" file a patch with its abstraction dependencies included, saving possible search-path confusion. 4) maybe also somehow avoid the embarassing necessity for invisible "float" and "floatarray" canvases. Probably someone has named a patch "float" and suffered for it.
The main thing I was thinking about was (3) - because beginners are always copying patches out of the doc/... examples and then wondering why "output~" doesn't appear. If output~ were encapsulated in the patch itself that would save a lot of newbies a headache or two.
cheers Miller
On Thu, Jan 19, 2023 at 03:04:02PM +0100, IOhannes m zmoelnig wrote:
On 1/19/23 13:00, Dan Wilcox wrote:
Without reading your reply in depth, it calls to mind my feeling that it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala:
[clone pd …]
right. though i think this is somewhat orthogonal to the "other stuff".
i thought about going to open a feature request along your suggestion (though my idea would have been to just drop the entire object specification, as in [clone 10], in order to be able to create cloned "subpatches".
i didn't do it because I wondered how to handle arguments (both the patch counter and user-provided args) - as per the "definition" of subpatches (aka "[pd]"), they inherit all the args from the parent canvas.
in the meantime i have changed my mind and i now think that it is probably not so complicated: subpatches within [clone] could just use an implicit "dummy-abstraction" that wraps the subpatch even though it technically is stored in the patch file that contains the [clone] object. arguments are visible in the subpatches as they are passed to [clone].
consider [clone pd 10 lop 500]. clicking on the [clone] object would open up a subpatch [pd 0 lop 500], where you can reference the 3 arguments, with $1="0" (that is: the clone-index), $2="lop" (which i only put there to make it obvious what the [clone] instance is used for), and $3="500" (e.g. the curoff frequency). all the subpatches share the same $0, but this is distinct from the $0 in the patch that contains the [clone] object.
the reason for this is mostly to separate the [clone pd] consistently from ordinary [pd] subpatches. (we do want *some* way to get the clone index into the subpatch, and the way this is handled with [clone] is via $1. this however would overwrite any $1 passed to the abstraction containing the [clone] object. therefore the other dollargs for the abstraction (including $0) shouldn't propagate to the [clone pd] either, as this would be most confusing)
probably i will create a feature request for this.
gdmasr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev