[PD-dev] [clone] with subpatches (was Re: multichannel signals, preliminary support)
IOhannes m zmoelnig
zmoelnig at iem.at
Thu Jan 19 15:04:02 CET 2023
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>
More information about the Pd-dev
mailing list