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
- Subpatches - single fixed code blocks
- Aliases - reusable code blocks within the main file
- Abstractions - reusable code blocks in separate files
- 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@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-