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