[PD] here I go again..dynamic abstractions

[Phil Stone]

This has been an interesting discussion about the philosophy behind 
dollar-sign symbols in Pd, but it seems to me like most participants are 
talking around Georg's original point at the head of the thread: it's 
inconvenient to get $0 (the "unique-id-for-this-abstraction" value) into 
a message, and its exclusion from message boxes seems arbitrary.

Why arbitrary?  It's very clear that dollar symbols mean different 
things in messages than they do in abstractions -- that is not the 
issue.  In fact, $0 is a special case *when used as an abstraction 
parameter* as well -- it does not have anything close to the same 
meaning or function as $1, $2, etc. (i.e., initialization parameters).  
Yet, it is still allowed in abstractions.  Why does the same reasoning 
not hold for message boxes?  It is a perfectly valid use-case to send an 
abstraction-id (from the message's containing abstraction) in a message. 

This whole question might have been avoided if $0 did not start with a 
dollar sign (I think someone mentioned this already).  But just because 
it does, why is it excluded from message boxes?  At least one other 
response in this thread has gone so far as to suggest that since $0 
doesn't have any meaning in a message box, it should be overloaded for 
something else (other than the unique abstraction identifier).   No, 
please!   :-)  Despite all the discussion in this thread, I have yet to 
see a reason for this exclusion that wouldn't apply equally to using $0 
as an abstraction-id.


Phil Stone
pkstonemusic.com


Mike McGonagle wrote:
> On Mon, Feb 9, 2009 at 3:45 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>   
>> I think it would make sense (both pedagogically and practically) if $0 in message boxes actually _did_ something.  Incrementing per message box would be one option, but expanding to a user-defined symbol or float could be very useful:
>>     
>
> Actually, for me, I always think of the word "CONTEXT". An abstraction
> is one context, and the meanings of the $ args means one thing. While
> in a message, a $ arg means something completely different. Once I
> realized that the two are not the same thing, it made sense.
>
> If the $ args had the same meanings in both an abstraction and a
> message, there would be no way to create a message inside of an
> abstraction that allowed for $ args that were unrelated to the $ args
> in the abstraction.
>
> In other words, if they were the same thing, there would be no way to
> create a variable message that had more args than there were in the
> abstraction itself.
>
> Mike
>
>
>   
>> [loadbang]
>> |
>> [f $0]
>> |
>> [; set $0(
>>
>> That way, message box $0 is set by an incoming message: it then sets all current (and future) message box $0's for the patch/abstraction.  Alternatively, you could use it for other stuff, like a substitution for pd-my-complicated-and-tiresome-to-type-subpatch-name.
>>
>> abstraction $0: set by pd, unique abs instance identifier, common to all object boxes
>> message box $0: set by user through msg box, common to all abstraction instance msg's
>>
>> Seems like that would be consistent with the language as far as I understand it.
>>
>> -Jonathan
>>
>> --- On Mon, 2/9/09, Matt Barber <brbrofsvl at gmail.com> wrote:
>>
>>     
>>> From: Matt Barber <brbrofsvl at gmail.com>
>>> Subject: Re: [PD] here I go again..dynamic abstractions
>>> To: "PD-List" <pd-list at iem.at>
>>> Date: Monday, February 9, 2009, 9:01 PM
>>> [f $0]-[message $1(  is conceptually different from [message
>>> $0(  for
>>> the same reason that [f $2]-[message $1(  is conceptually
>>> different
>>> from [message $2(  (and would be, even if $0 had any
>>> meaning in a
>>> message box).  When I teach I always start with dollar-sign
>>> expansion
>>> in message-boxes, since it's simpler and easier to
>>> comprehend.  Then
>>> when this issue comes up when they move to dollar-sign
>>> expansion in
>>> abstractions (and it always does come up), you can help
>>> them think it
>>> through with what they already know about message boxes.
>>>
>>> I only see two options:  one is to use a different
>>> dereference symbol
>>> for abstraction arguments in message boxes -- but why worry
>>> with that
>>> since it's easy enough to get abstraction arguments
>>> into messages at
>>> "run-time?" -- the other is to make an exception
>>> and have special
>>> behavior for $0 in message boxes (that is, make it the same
>>> as in
>>> object boxes) -- but then this probably breaks the
>>> consistency of the
>>> language.
>>>
>>>
>>> Matt
>>>
>>>
>>>       
>>>> Date: Mon, 09 Feb 2009 13:33:36 +0100
>>>> From: Georg Werner <georg at fricklr.de>
>>>> Subject: Re: [PD] here I go again..dynamic
>>>>         
>>> abstractions
>>>       
>>>> To: pd-list at iem.at
>>>> Message-ID: <499022A0.7080702 at fricklr.de>
>>>> Content-Type: text/plain; charset=ISO-8859-1;
>>>>         
>>> format=flowed
>>>       
>>>> hi,
>>>>
>>>> Frank Barknecht:
>>>>  > How about making $0 in messages be a message
>>>>         
>>> counter?
>>>       
>>>> if somebody really needs that - i dont ;)
>>>>
>>>> ok, i give up. i think we are on a rather
>>>>         
>>> philosophical point now.
>>>       
>>>> but i had a lot of times when students where asking
>>>>         
>>> why they have to
>>>       
>>>> write [f $0]-[foobar $1( instead of [foobar $0(. so
>>>>         
>>> this came up from a
>>>       
>>>> users point of view.
>>>> after getting all your input (thanks). i think Claude
>>>>         
>>> brought up the
>>>       
>>>> most logical solution, because this makes the
>>>>         
>>> different functions of $
>>>       
>>>> obvious and obsolete. And it would help users and
>>>>         
>>> devs. (i know it will
>>>       
>>>> be a long way - cause it will break some patches ...
>>>>         
>>> :( )
>>>       
>>>>  > $ in message boxes is unfortunate.  If there was
>>>>         
>>> a different symbol,
>>>       
>>>>  > perhaps #, you could combine both phases in one
>>>>         
>>> object box to avoid
>>>       
>>>>  > jumping through pointless hoops.
>>>>  > [$0-#1-$2-#3( would be nice, but as Pd is now,
>>>>         
>>> it's a nightmare.
>>>       
>>>> not a nightmare, but this is one point why Pd is
>>>>         
>>> harder to learn for
>>>       
>>>> beginners than it has to.
>>>> georg
>>>>         
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>       
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>>     
>
>
>
>