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__