[PD] some macro ideas
fbar at footils.org
Tue Oct 3 14:55:55 CEST 2006
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:
then will become:
> 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
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.
Frank Barknecht _ ______footils.org_ __goto10.org__
More information about the Pd-list