On Tue, 3 Oct 2006 12:41:12 +0200 Frank Barknecht fbar@footils.org wrote:
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.
Yes, I totally understand, you explained it very well, here and before and it makes perfect sense. Nobody is suggeting replacing abstractions, or dumbing them down. My personal gripe is that they must currently be in separate files and there is no continuum/route between abstractions and subpatches except by manually copying, pasting and changing the code.
The ability to "recast" an abstraction/function as a fixed code block (or a swift mechanism to promote subpatches) in no way diminishes the value of abstractions, but it is very useful.
Suppose you have created a patch using an abstraction. As it happens the abstraction is an old familiar you've used in many patches, but on this occasion you need some slightly different behaviour. So you edit the abstraction thinking that you're doing so safely and taking into account all previous uses. You don't even discover that you just broke a whole load of your patches until days or weeks later when you try and load them. Of course you could just say copy the abstraction and work on that, but you end up with an ugly mess of special cases
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.
Is it so different? In both cases you created a new local copy replacing $ (initialise time arguments) with inlets instead. Granted, you cannot now say [pd MySubpatch arg1 arg2..] and must explicitly set the parameters through the inlets, but that's what you wanted.
I didn't fully understand the power of abstractions until you showed me the [nqpoly] object invisibly creating multiple copies of the same thing, that is way cool, and very desirable! Which is why the idea of an "alias" isn't quite the same thing as an "embeded abstraction". I guess a better way of explaining what I mean is that an alias is a subpatch with local scope, so you can define $0- type things inside it like tables and then copy it with impunity, but if you edit the "master" copy the others all follow suit.
I think the missing ingredient in all this are "local variables" for subpatches.
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.
That sounds nice. It gets around having to remember which was your "master alias", but then again perhaps a more elegant method is that (they are true aliases) editing *any* copy is equivilent.
What are the issues making this difficult? - remember I still have a very limited appreciation of the Pd kernel code.
Cheers,
a.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list