[PD] some macro ideas

Frank Barknecht fbar at footils.org
Tue Oct 3 12:41:12 CEST 2006

padawan12 hat gesagt: // padawan12 wrote:

> But those that really *use* Pd a lot probably agree with me that another
> reason for abstractions is to test/edit a piece of code in many places,
> and once you've got it right cast it in stone as a subpatch.

Well, I don't agree at all. ;) People should learn the many
possibilities and advantages of abstractions instead.

I think, I've written about my view here several times, so I will only
repeat my main point: subpatches and abstractions are something
completely different! 

To those who program with text based languages: subpatches are code
blocks, they are the "{...}" in Perl or C or the indented blocks in
Python. Abstractions however are functions. They are the "func" in the
"int func(arg){}" of C or in the "def func(arg):..." of Python. The
two important differences are the "arg" that is possible to pass and
the fact, that a function is defined in exactly one place and then,
when it gets called, you can be sure, that it always show the same
behaviour.  Subpatches however may all behave in a different way and
they don't accept arguments. 

IMO one should not try to dumb down a "func(arg)" into a "{}" at all.

What's missing in Pd may be a way to embed "func(arg)" in the same
file, but this is something different from converting it to a

We would probably need to create a way to declare and define an
embedded abstraction in one place of the patch, maybe using a
subpatch-like object [def myEmbeddedAbstraction args] which would have
its own canvas to edit it like a subpatch, and then one could use
[myEmbeddedAbstraction args] inside just this patch. But I guess that
this is as tricky to implement as the [import] object that was
discussed recently on pd-dev. But maybe it isn't.

 Frank Barknecht                 _ ______footils.org_ __goto10.org__

More information about the Pd-list mailing list