Em qui., 19 de jan. de 2023 às 16:51, Miller Puckette <msp@ucsd.edu> escreveu:
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.

Oops, sorry you missed that. I did it for Pd 0.52 and the reasoning was that we actually had like three copies of it in different places, and we were also trying to use it in yet other places. It just felt reasonable to me to keep it in a single place ('extra') and call it there. As I say in its help file "This is a simple abstraction that's widely used in Pd's documentation (help files and examples). It is included here in 'extra' just for convenience."

I also don't like setting the amplitude level with 'dB' by the way, and wouldn't mind if it got removed from 'extra'. I never use it myself, but it'd be good to try and keep just a single copy of it.

I actually like the idea this is offered so other people can use it if they want to keep things Vanilla. Something like this is quite useful for documentation of external libraries. I would actually like to use it in Cyclone's documentation. Also, some external's documentation were made using a similar abstraction called [output~] because it was available in Pd extended. If used now in Vanilla, a replaceable abstraction is found.

What if we design a new simple abstraction like that without the dB setting? I usually use the quartic curve you also suggest and we could just use a slider, it could still be called [output~].

cheers

 

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$
> >