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

[IOhannes m zmoelnig]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230119/bdfbb948/attachment.sig>