[PD-dev] Removing [output~]? (was [clone] with subpatches)

Thu Jan 19 21:08:01 CET 2023

Em qui., 19 de jan. de 2023 às 16:51, Miller Puckette <msp at 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 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$
> > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230119/cc8f5e07/attachment-0001.htm>