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 _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
