[PD-dev] [clone] with subpatches (was Re: multichannel signals, preliminary support)

[Miller Puckette]

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