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

[Alexandre Torres Porres]

Em qui., 19 de jan. de 2023 às 15:36, Miller Puckette via Pd-dev <
pd-dev at 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 at lists.iem.at
> > https://lists.puredata.info/listinfo/pd-dev
>
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230119/2af54238/attachment-0001.htm>