I did it just fine, using $1 and passing a parameter "one" then "two" "three" etc. for the various instances, then invoking the subpatch in each instance with "pd patchname $1" to pass the unique name parameter on to the subpatch. I was sending sinesum messages to the array and the $1 in a message doesn't pick up the parameter "one," so I used a "symbol $1" object to hold the parameter, then passed that to a pack obj, which passed the parameter and other variables on to the sinesum message, which rewrote the array. That doesn't seem very clear...
Message: 2 Date: Thu, 02 Oct 2003 03:34:00 +0200 From: derek holzer derek@x-i.net To: pd-list@iem.at Subject: [PD] dynamic-named arrays
second late night abstract control-data question:
is it just me, or is it tricky to name an array from a creation argument? naming the array $2-zample in an abstraction with creation arguments(1 2), for example, doesn't seem to hold water, as subpatches
[where i can see in the window title bar that the creation arguments are carried through, i might add!] with a "tabread~ $2-zample" can't seem to locate it.
or does this work, and i am doing something else wrong? ;-)
d.
Hallo,
0 hat gesagt: // 0 wrote:
I did it just fine, using $1 and passing a parameter "one" then "two" "three" etc. for the various instances, then invoking the subpatch in each instance with "pd patchname $1" to pass the unique name parameter on to the subpatch.
This is a common misunderstanding: argument passing *does not work* for subpatches ("pd something"), it only works for abstractions (file abstr.pd used as [abstr] in a patch). See attached proof. So it's useless to use anything after the subpatch's name in [pd subpatch].
ciao
Frank Barknecht _ ______footils.org__
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
This is a common misunderstanding: argument passing *does not work* for subpatches ("pd something"), it only works for abstractions
it's true but it would be a great feature to have that.
But an uncompatible one! And I'm not sure if it actually would be great. I do rely on this very often and on the character of a [pd subpatch], that it is just a curtain to hide things from view, but that it has no semantic meaning at all.
I like having the arguments of the surrounding abstraction available inside the subpatch without further work. Also it is important to be able to $0-send through subpatch borders, but not through abstraction-borders. I see a subpatch as a full part of the patch that just isn't visible (or is, through GOP!)
ciao
Frank Barknecht _ ______footils.org__
Hi Frank, you are right, but i'm not talking about changing the current behavior (and breaking things), but rather extending it. There could for example be $$0-$$9 parameters which relate to the subpatch parameters, not to the ones of an abstraction. Pix is also right, stating that one could also make an abstraction every time such a behavior is needed, but i'd rather have it easier to handle. Additionally, in PD i also often miss the distinction between $0-$9 and #0-#9 that Max has, the first being message parameters and the latter ones being abstraction arguments... but i understand that it might be too late for introducing that in PD.
best greetings, Thomas
----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.at Sent: Friday, October 03, 2003 12:51 AM Subject: Re: [PD] dynamic-named arrays
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
This is a common misunderstanding: argument passing *does not work* for subpatches ("pd something"), it only works for abstractions
it's true but it would be a great feature to have that.
But an uncompatible one! And I'm not sure if it actually would be great. I do rely on this very often and on the character of a [pd subpatch], that it is just a curtain to hide things from view, but that it has no semantic meaning at all.
I like having the arguments of the surrounding abstraction available inside the subpatch without further work. Also it is important to be able to $0-send through subpatch borders, but not through abstraction-borders. I see a subpatch as a full part of the patch that just isn't visible (or is, through GOP!)
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
you are right, but i'm not talking about changing the current behavior (and breaking things), but rather extending it. There could for example be $$0-$$9 parameters which relate to the subpatch parameters, not to the ones of an abstraction.
Yes, this wouldn't break anything.
Pix is also right, stating that one could also make an abstraction every time such a behavior is needed, but i'd rather have it easier to handle. Additionally, in PD i also often miss the distinction between $0-$9 and #0-#9 that Max has, the first being message parameters and the latter ones being abstraction arguments...
The disctinction between message arguments and abstraction arguments as well as the distinction between subpatches and abstractions are two of the most confusing things to understand for Pd beginners. I think, the first problem could be alleviated by introducing #1 arguments for messages and still supporting, but maybe deprecating the $1 form here. Although that is still another way then in Max.
The subpatch/abstraction difficulty is more a "linguistic" problem. As abstractions could also be described as "subpatches", because they are subordinate patches inside another patch, it is easy to confuse them with the real subpatches according to Pd vocabulary.
At least I had a hard and long time figuring all this out initially. The html documentation is correct here (mathematically and logically) but it should be a lot clearer and deeper in this topic. For example, abstractions are explained as a subchapter in the chapter called "subpatches", indicating abstractions *are* subpatches, which they aren't. They share some behaviour (hidden, GOP, open on click,...) but other things they don't share (argument passing, localized variables, data structure handling,...)
Maybe a table describing differences and shared behaviour is needed.
ciao
Frank Barknecht _ ______footils.org__
On Fri, 3 Oct 2003, Frank Barknecht wrote:
The subpatch/abstraction difficulty is more a "linguistic" problem. As abstractions could also be described as "subpatches", because they are subordinate patches inside another patch, it is easy to confuse them with the real subpatches according to Pd vocabulary.
Throwing some pseudorandom ideas in:
Now that I think about it, it is akin to the word "subprogram", which has been traditionally a name for what is now called "procedure" or "method". (don't use the word "subroutine" in front of me!)
Well, just by looking at the construction of that word, "subprogram" could be any kind of program element that can stand as a program on its own, where "on its own" is quite loosely defined. Therefore in modern programming a "subprogram" could be easily made to mean a class, for example.
I'm making a parallel with mathematics, where subsets are sets, and subgroups are groups, and subspaces are spaces, and wondering whether the word "subprogram" could follow that.
Now, back to "subpatches":
If it were following the compsci convention, "subpatch" would be the name for an abstraction, but right now, it's more like "blocks" in C (loose braces, just a nonautonomous subsection of a procedure).
If it were following the math convention, "subpatch" would possibly be a more general name inclusive of several concepts but maybe not what is currently called a "subpatch", depending on how "stands on its own" gets defined here.
Mathieu Bouchard http://artengine.ca/matju
are you so sure?
you would have to choose the parameters very carefully as editing the object in any way causes the contents of the subpatch to be destroyed.
might i suggest that if you are making something accept parameters, that you should be making an abstraction, so that you can use it again, with different parameters?
i rarely use subpatches. i have a huge personal library of abstractions as a result ;)
pix.
On Fri, 3 Oct 2003 02:41:01 +0200 "Thomas Grill" t.grill@gmx.net wrote:
This is a common misunderstanding: argument passing *does not work* for subpatches ("pd something"), it only works for abstractions
it's true but it would be a great feature to have that.
raise the headroom, Thomas
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
I think the design thought is that an abstraction is just that, a small patch that can be used in multiple contexts, and therefore you should be able to load it like an external.
Subpatches are particular to the current patch, not "abstract" (not in the same way anyhow). I think of subpatches as more for cleaning up, not creating multiple levels of abtsraction in a patch. The abstraction can tune itself to whatever patch its in via the creation arguments, a subpatch is made to do a certain thing in a patch, so does it need to be as flexible?
I don't think it would be a bad thing to have arguments in a subpatch, but I can see little reason why you would do this rather than using an abstraction. (other than being able to stick everything in one file, but if you are writing a subpatch that needs to tune itself to the circumstances than why not make it abstract enough to be used in other patches?
Ben
This is a common misunderstanding: argument passing *does not work* for subpatches ("pd something"), it only works for abstractions
it's true but it would be a great feature to have that.
raise the headroom, Thomas
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi Ben,
I don't think it would be a bad thing to have arguments in a subpatch, but I can see little reason why you would do this rather than using an abstraction. (other than being able to stick everything in one file, but if you are writing a subpatch that needs to tune itself to the circumstances than why not make it abstract enough to be used in other patches?
i program quite a lot (either with programming languages and patcher-like systems) and it's my experience that one often needs to do quick and dirty things instead of taking the time to design a reusable module. I find my project folders cluttered with abstractions that i just needed to encapsule a part of a patch - i think i'm more a supporter of self-consistency. I don't say that there is a real necessity for subpatcher arguments but it's probably another level of flexibility.
good gain, Thomas
On Fri, 3 Oct 2003, Thomas Grill wrote:
i program quite a lot (either with programming languages and patcher-like systems) and it's my experience that one often needs to do quick and dirty things instead of taking the time to design a reusable module. I find my project folders cluttered with abstractions that i just needed to encapsule a part of a patch - i think i'm more a supporter of self-consistency. I don't say that there is a real necessity for subpatcher arguments but it's probably another level of flexibility.
Instead of subpatcher arguments, I would propose "subabstractions". This is like most programming languages, where the concept of subprogram is distinct from the one of file. In that case, you can make abstractions local to a patch, which means you need a menu to access them.
The current design can still be excused by pointing at jMax, C74-Max, Matlab, etc. which don't distinguish subprograms from files either. But I'd like my idea to be judged for what it is. (I already talked of that idea here, with mixed results...)
Btw, given enough subpatches, PD's policy of automatically opening all of them is sort of annoying. I prefer the jMax behaviour, which is to only show the top level by default.
Mathieu Bouchard http://artengine.ca/matju
-
0 -
ben＠ekran.org -
Frank Barknecht -
Mathieu Bouchard -
pix -
Thomas Grill