[PD] some macro ideas

[padawan12]

I think you have answered your own question with point 1.
Those creation arguments are in essence abstraction parameters.


But point 2 has some merit and it's been raised before. The necessity
for abstractions to be separate files is imho one of Pds most significant
flaws. I avoid using abstractions entirely because even with the most
careful management they are more trouble than they are worth.

A "convert abstractions to subpatches" or "embed abstractions" utility
would be of great practical benefit. You have spotted one of the difficulties
in doing this, substituting parameters in each instance, and you are correct
it's nothing more than a substitution problem. But which "version" do you
use if there is an identically named abstraction inside and outside your
patch with different functionality? I don't know that there is a sensible 
order of precedence yet, like abstractions in the path > abstractions in the
same directory as the patch > abstractions inside the patch (aliases).

Besides, converting abstractions to sub-patches would be a one way street
which prevented you from editing one piece of code and having it update in
many places... that's the real reason for abstractions in the first place.
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.

That is why I suggested the concept of "aliases" as a halfway marker
between abstractions and subpatches.

I think there is groundwork to be done before this can move forward.
Namespaces and scope are two ugly aspects of Pd right now that are
being worked on. Once this is sorted out we could move towards

1) Subpatches - single fixed code blocks
2) Aliases - reusable code blocks within the main file
3) Abstractions - reusable code blocks in separate files
4) The ability to cast/convert between each.


The ability to move "downwards" from abstractions to aliases to subpatches
would be easy, but the reverse would require some more work, for example
mapping each $n argument onto an inlet and each inlet back to a $n argument.
I think the smart coders know it would be premature to make this
switch at present and it would probably get broken. In my opinion this
is worth getting right even if it means sacrificing backwards compatability,
and it's not too late in the day to do it. 


On Tue, 3 Oct 2006 10:46:09 +0300
"ugur guney" <ugurguney at gmail.com> wrote:

> # Hi everybody,
> # This morning two ideas about macros which could make our lives easier has
> come to my mind.
> # 1) There are these objects, every time we create them, we add some
> messageboxes to control them. For example, [writesf¨~] with [open(, [save(
> and [stop messages( or [netsend] with [connect(, [disconnect(, [send(
> messages etc.
> # What if, these absolutely necessary messagebox's are created when we
> created these objects, so we do not have to look to their help patches every
> time. Or there could be a new type of abstractions, which includes these
> message boxes information, at the same level with them.
> 
> # 2) For example, I have a patch witch uses a lot of abstractions. And every
> time a send it to my friend, I forget to attach some of these abstractions,
> and it did'nt work on his/her computer. So, what if, there were a button,
> which changes every abstraction in the patch with a sub-window. e.g, one of
> my abstractions (partial.pd) [partial] would changed with [pd partial].
> # hmm... I looked and saw that sub-windows does not take creation arguments,
> so these could be a problem...
> # Aha! Creation arguments could be hard coded in the sub-window. e.g:
> [partial 2 cos] => [partial]
> in which
> 
> [r fundFreq]
> |
> [* $1]
> 
> 
> =>
> 
> [r fundFreq]
> |
> [* 2]
> 
> # How could these ideas be implemented? Do you have suggestions?
> # Thank you very much for your elegant, educative and funny conversations...
> -ugur guney-
>