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__