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

[Phil Stone]

Roman Haefeli wrote:
> 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
>   

Actually, all it would take to convert all old patches to this new form 
is one line of perl with a well-constructed regular expression.  I 
agree, still, that it is probably not going to happen.


Phil


> 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)...