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@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-Da... )
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__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...