[PD] some macro ideas

[padawan12]

On Tue, 3 Oct 2006 12:41:12 +0200
Frank Barknecht <fbar at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list