[PD] Finding "$0" and dealing with it in messages

Fri Nov 13 21:55:03 CET 2009

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 <brbrofsvl at 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 <porres at 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 <brbrofsvl at 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 <porres at 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 <reduzierer at yahoo.de>
> >> > wrote:
> >> >>
> >> >>
> >> >>
> >> >> Am 12.11.09 17:21 schrieb "Alexandre Porres" unter <porres at 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
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20091113/3a190965/attachment.htm>