[PD] some macro ideas

[Frank Barknecht]

Hallo,
padawan12 hat gesagt: // padawan12 wrote:

> 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.

Yes, but in my view, subpatches and abstractions serve different
purposes (like blocks and functions), so a direct route to convert
between them is not necessary. Or at least a way to convert an
abstraction to a subpatch is not necessary. The other way around may
be nice sometimes, however just typing Ctrl-N and copying over the
subpatch's contents is close to convenient.

> 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.  

I would agree that embedding abstractions can be useful, but where is
making a subpatch out of an abstraction useful, when you loose access
to abstraction features like arguments or edit-once-use-everwhere?
OTOH adding these features to subpatches would in the end make
subpatches be abstractions, and you would actually loose what
subpatches were useful for: code organization usign code blocks (see
below for more detail).

> 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

I would say that this is just a matter of organizing things and
keeping the environment clean. if the behaviour of an abstraction
changes significantly it probably would have been better to save it
under a different name. Or save it locally next to the main patch, and
not in a global abstraction-directory. Another thing I often do is
make "wrapper abstractions": I don't change the abstraction itself,
but put it inside another abstraction which adds some functionality:

  [myabs] 

then will become: 

  [inlet]
  |
  [pd do_something]
  |
  [myabs] 
  |
  [pd do_something_more]
  |
  [outlet]


> 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.

But I *want* my subpatches to share the scope of the surrounding
patch! ;)

I like to compare subpatches to curtains: I use subpatches to put
things I'm done with behind a curtain so I don't see them anymore. The
stuff hidden by that curtain is still in the same room, I can still
talk to a person behind it, I know what's behind that curtain, it's
good to have it there, I can take a look behind the curtain quickly if
I want to. Being able to talk to a person behind a curtain is
equivalent to subpatches sharing $0 with the surrounding patch.

Abstractions however are more like people that live in another flat,
people I call over the telephone line: If I want to go out for a beer,
I call my friends. I can call them from everywhere I am, because they
always have the same phone number(s) everywhere I am. If I need to
order a pizza, I call the pizza service. But I don't want to have the
pizza service behind a curtain in my living room. It may be nice to
have a pizza service in the same house you live, though, as an
embedded pizza service abstraction.

> > 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.

Hm, yes, that would probably make more sense.

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__