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

[Miller Puckette]

Hmm,  I didn't notice that output~ got moved into extra... I think we should put it
back in doc!  The DB-based way of setting levels is wrong-headed and confusing.

cheers
Miller

On Thu, Jan 19, 2023 at 04:18:53PM -0300, Alexandre Torres Porres wrote:
> 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://urldefense.com/v3/__https://agraef.github.io/purr-data-intro/Purr-Data-Intro.pdf__;!!Mih3wA!CGsqse41ny34T_MAY0x499BvsvMM7CJ6RPCLqjl-oOB1x1vhOajH8z_W0iU4RR25rRRZUgrKoA$  )
> 
> 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://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!CGsqse41ny34T_MAY0x499BvsvMM7CJ6RPCLqjl-oOB1x1vhOajH8z_W0iU4RR25rRS3QMzWvA$ 
> >
> >
> >
> >
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at lists.iem.at
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!CGsqse41ny34T_MAY0x499BvsvMM7CJ6RPCLqjl-oOB1x1vhOajH8z_W0iU4RR25rRS3QMzWvA$ 
> >