Oh, cool, yeah, that is a nice design, I see it now. but anyways, I still see $0 as locality and the rest as inheritance, as you are just still making a child inherit (by $1) a parent's local $0 ID.
> I personally love the idea of using $0 as the selector > of the abstraction -- its name or filename, and $$ as > its ID, but too late for that now. now that wasn't clear for me, but if we keep on it I suggest we might need to change the thread name maybe. I hope this thread would stick to the point that the find feature could do a better job by finding "$0", and that "$0" could be used in messages since it is useless the way it is. thanks alex On Fri, Nov 13, 2009 at 6:27 PM, Matt Barber <brbrof...@gmail.com> wrote: > I am saying two things: > > 1) Without $0 or something similar, the only way to guarantee similar > locality would be through use of $1 or $n -- you would have to > manually give each instance an instance number. Sometimes you even > want to be able to group instances in the way you suggested. I'm not > sure of the history of Pd, but if $0 was implemented after > abstractions with arguments, then manually assigning locality was > probably necessary. > > 2) Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by > various helper abstractions within a larger, higher-functioning > abstraction. This is especially the case with dynamic patching -- > imagine, say, a "bell synthesis" patch using a dynamically created > bank of enveloped oscillator abstractions. In that case, you'd want > each oscillator abstraction to [throw~] to the same [catch~] within > the parent "instrument" abstraction. To do this, you could have > [catch~ $0-out] within the parent, and [throw $1-out] within each > child, while passing the parent's $0 to the children. > > So all I'm saying is that $1-$n often plays a really important role in > locality, in addition to a number of other things, and to me it seems > almost natural to use $0 as an analogy for this role. I personally > love the idea of using $0 as the selector of the abstraction -- its > name or filename, and $$ as its ID, but too late for that now. > > Matt > > On Fri, Nov 13, 2009 at 3:01 PM, Alexandre Porres <por...@gmail.com> > wrote: > > hmm, I am sorry, I don't think I got what you meant... could you give an > > example please? > > The way I see is that $1...$n are related to the inheritance concept. > They > > could be used inside [send~] & [receive~] objects to force some sort of > > locality, but you can't really guarantee locality by that, it is just > some > > way around that is not 100% safe, cause if you have [s $1-gain] in an > > abstraction, and $1 inheriting "A" for instance, a [s A-gain] object in a > > parent patch (or even on another opened patch) would still get the value > > globally. > > cheers > > alex > > > > On Fri, Nov 13, 2009 at 5:28 PM, Matt Barber <brbrof...@gmail.com> > wrote: > >> > >> Without $0, one would have to use $1 ... $n for locality. $0 of a > >> parent patch often needs to be passed as $1 to a child for proper > >> locality, for instance, so I don't think they are necessarily THAT > >> different conceptually. > >> > >> Matt > >> > >> On Fri, Nov 13, 2009 at 11:49 AM, Alexandre Porres <por...@gmail.com> > >> wrote: > >> >> Calling this an exception creates > >> >> the impression, that $1 in a message > >> >> is the same as in an object. > >> > Hmm, I see you have a point! But I am just used to consider "$0" and > >> > "$1, $2 > >> > ... $n" different/separate things, being "$0" solely a locality > sintax. > >> > Putting them as separate concepts I see "$1, $2 ... $n" as two > different > >> > things wether in messages or objects, and that "$0" is just useless in > >> > messages. > >> > Anyway, I am cool with what needs to be done in order to put "$0" in > >> > messages, I still think it's a bit of an unnecessary hassle, but it > >> > ain't > >> > that much of a big deal after all. > >> > The thing that had no other way around was using the Find feature to > >> > actually find them, so I thought about bringing this all up: the > >> > hassle and > >> > the problem. > >> > I now see that uncheking "whole word" in the new version is just > another > >> > "way around" rather than actually getting the Find feature to look for > >> > "$0", > >> > or even for the window number once we explicitly tell it which one it > >> > is. > >> > So, nerverminding about "$0" in messages, I would still make a point > >> > here > >> > for the Find feature to be able to find "$0", I hope it isn't much > >> > hassle > >> > getting it to do so. > >> > Thanks a bunch folks! > >> > Cheers > >> > alex > >> > > >> > On Fri, Nov 13, 2009 at 8:03 AM, Roman Haefeli <reduzie...@yahoo.de> > >> > wrote: > >> >> > >> >> > >> >> > >> >> Am 12.11.09 17:21 schrieb "Alexandre Porres" unter <por...@gmail.com > >: > >> >> > >> >> > But I totally disagree, I have been teaching a lot basic Pd around, > >> >> > and > >> >> > people > >> >> > always get confused and think they can just throw "$0" in messages. > >> >> > So I > >> >> > have > >> >> > to state and reinforce that there is an exception that it doesn't > >> >> > work > >> >> > on > >> >> > messages. > >> >> > >> >> Calling this an exception creates the impression, that $1 in a > message > >> >> is the same as in an object. > >> >> > >> >> > Without an exception at all, it should be easier to get it, as I > >> >> > understand. > >> >> > >> >> Agreed. But currently, the only thing that makes $0 in a message > >> >> exceptional > >> >> is the fact, that it has no meaning at all. Making it be replaced by > >> >> the > >> >> canvas identifier wouldn't make it less exceptional at all. > >> >> > >> >> roman > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> ___________________________________________________________ > >> >> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! > >> >> Mail: > >> >> http://mail.yahoo.de > >> > > >> > > > > > >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list