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

[Roman Haefeli]

Finally, we agree. I also think, that using $ twice is confusing, when
the uses are so different.

Personally, i wouldn't mind, if Pd would be changed instantaneously
while breaking backwards compatibility. But i don't think, that it is
realistic.

roman



On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote:
> Matt Barber 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.
> 
> Good points, all.
> 
> > 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.
> >   
> 
> I can't disagree with this, either.  Though, in the spirit of wishful 
> thinking, I'll go it one further: abstraction arguments would ideally 
> have a different form than message arguments.  E.g. #0...#n for message 
> args., and $0...$n for abstraction args. (or, the other way around, 
> whatever)...  Then (and only then, I think) would this discussion not be