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