[PD] shortcuts for patching

Frank Barknecht fbar at footils.org
Tue Jun 6 23:55:51 CEST 2006


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__




More information about the Pd-list mailing list