PDDP patch for subpatches/abstractions WAS Re: [PD] shortcuts for patching

Hans-Christoph Steiner hans at eds.org
Thu Jun 8 14:32:42 CEST 2006


That is a great description, its like a page out of the Pd textbook.   
Feel like making that a PDDP patch?  It would fit very well in a  
later page of doc/tutroials/intro.  There is a lot of content there  
already, but its really poorly organized (FYI).

.hc

On Jun 6, 2006, at 11:55 PM, Frank Barknecht wrote:

> Hallo,
> padawan12 at obiwannabe.co.uk hat gesagt: //  
> padawan12 at obiwannabe.co.uk wrote:
>
>> Two things would help with this. Firstly the process of creating a
>> [pd mysubpatch] object, copying and pasting all elements into it
>> while keeping track of all inlets and outlets could be much
>> improved. Selecting a whole bunch of objects and simply clicking a
>> "make subpatch" that found all terminal signal paths at the
>> boundaries and automatically asigned [inlet/inlet~/outlet/outlet~]
>> would be lovely.
>
> Great idea, that indeed would be lovely.
>
>> To be honest I don't entirely get "abstractions".
>
> As you are a programmer, you know the difference between a code block
> and a function: subpatches are code blocks and abstractions are
> functions, kind of. The real power of abstractions is not, that they
> are in their own files so they can be used for code reuse. The real
> power is, that they can accept arguments.
>
> People who patch without using abstractions completely miss this
> feature, they use a programming language without function(s).
>
> To make this a bit less abstract: Think of the [+ ] object. You could
> clone it in Pd, but if you clone it as a subpatch like [pd add]  
> with trivial
> content, it would only be a [+ ] that doesn't accept an argument, that
> is, you couldn't do [pd add 3] to make a clone of [+ 3].
>
> However if you do an abstraction "add.pd" with:
>
>   [inlet]
>   |
>   [+ $1]
>   |
>   [outlet]
>
> you can use this just like the real [+ 3] and write [add 3].
>
> OTOH it is not of no importance, that abstractions are their own files
> and that all of them change their behaviour, if you change the one
> source file. Assume you made a silly mistake and used this to write
> [add]:
>
>   [inlet]
>   |
>   [- $1]
>   |
>   [outlet]
>
> If you already used [add 3] in a lot of patches, then you only need to
> fix this error in one place, to fix all occurences of [add]
> everywhere. If however you have one [pd add] with does [-] and the
> other [pd add]s do the correct [+], than that is very confusing and
> error prone, though it would be perfectly legal in Pd.
>
>> It's the fact they exist in separate files that makes the headaches.
>> I prefer to use everything in one file to get easier management.
>
> Just change your preferences. ;) Managing external files can be easy
> as well. You could for example always use a subdirectory called "pd"
> relative to your main patch to place your abstractions. Then instead
> of writing [pd subpatch] you could write [pd/abstraction] and put
> abstraction.pd inside the "pd"-subdir. It looks almost like a
> subpatch, can be zipped together with the main patch and still allows
> to use the full feature set of abstractions.
>
> Ciao
> -- 
>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list


________________________________________________________________________ 
____

"Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies."
                                                     - Amy Smith





More information about the Pd-list mailing list