Em qui., 19 de jan. de 2023 às 15:36, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
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.
Well, the thing is that now [output~] is an abstraction in 'extra', so Pd should find it now :)
But I think I see what you mean, and maybe Purr Data has implemented something similar. They have this [ab] object. For reference: "*The [ab] object is accompanied by a number of supplemental objects (abinfo, abdefs, abclone) which let you inspect and clone private abstractions. There’s also an “Abstractions” dialog which can be accessed via the Window menu. This will give you a quick overview of the private abstractions contained in a patch. Also, it will show you private abstractions which aren’t currently being used (i.e., don’t have any instances), so that you can select and then delete them if they aren’t needed any more*." (from https://agraef.github.io/purr-data-intro/Purr-Data-Intro.pdf )
This "private abstraction" is then a subpatch that is saved with the patch file. It can have arguments and they have their own "$0". There's [abclone] that can clone them too...
I like this idea as I have a few external objects that are abstractions which use [clone] and I need yet another abstraction to call inside clone. This would make things much simpler as many times you don't really want to create and clone a "real abstraction" (one you'd have for different purposes other than using in a particular [clone] object in your patch).
cheers
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