[PD-dev] [clone] with subpatches (was Re: multichannel signals, preliminary support)

[Sebastian Shader]

+1 Often there is a need to replicate a [pd ] object with arguments, that is specific to the parent's use/implementation.
Patch-local 'embedded' abstractions have been mentioned as the way to achieve that in a consistent way too.

I'm not sure the 'window' dialog thing is necessary in vanilla though. Generally it's the responsibility of the author to remove any other unused objects and I'm not sure why [ab ] should be different.

2 cents on [output~]: I also agree that some kind of standardized output-volume-slider abstraction should be offered, whatever it may be.. everything else in the help files can generally be copy/pasted into actual patches and used, and it's reasonable to have a simple abstraction for help files, it's almost always desirable to have some kind of volume control before [dac~] and for authors who want to use an output limiter or something they can just not use it.. seems at least as useful as the other abstractions in /extra.

>> 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://agraef.github.io/purr-data-intro/Purr-Data-Intro.pdf )
>
>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
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230119/7cd8bbb3/attachment-0001.htm>