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@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@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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
