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

Thu Jan 19 21:14:53 CET 2023

Aha, yes, let's do that.  It would be sort-of compatible with existing
patches (just the control would be different.)

One thing I never figured out was how to: (1) offer mono and stereo operation
int he same object; and (2) allow the level to be changed externally without
havin to add another (confusing) inlet.  So it's the lack of an all-around
"best" way to do it that's held me back from putting something in "extra"
so far.

But meanwhile, I think someday I should go ahead and split "extra" into 
true necessities (sigmund~, bonk~, and a couple of stupid compatibility
objects) and things that are "useful" (such as the reverberators).  Again
I've been held back by not having a clear definition of what I think those
things should be :)

M

On Thu, Jan 19, 2023 at 05:08:01PM -0300, Alexandre Torres Porres wrote:
> 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$
> > > >