[PD] some macro ideas
Frank Barknecht
fbar at footils.org
Tue Oct 3 12:41:12 CEST 2006
Hallo,
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
subpatch.
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.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
More information about the Pd-list
mailing list