[PD-dev] bind abstraction-canvas to full classname

[Hans-Christoph Steiner]

On Jan 14, 2006, at 1:02 PM, IOhannes m zmoelnig wrote:

> Mathieu Bouchard wrote:
>> On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
>>> abstractions require the .pd extension. with the 2nd patch i  
>>> submitted a
>>> ".pd" is appended to the canvas-receiver of an _abstraction_. the  
>>> "new"
>>> (currently: additional, but see the other mails on this topic)
>>> canvas-receiver consists of the classname (== relative-pathname +
>>> filename). there is no check whether the classname (how you call the
>>> object) contains a relative (or even absolute) pathname.
>> What's the use of being able to contact one (and only one) instance  
>> of an abstraction via a receive-symbol?
>
> do i guess this is a rhetoric question?
> btw, my patch does not contact one (and only one) _instance_ of an  
> abstraction, but _all_ instances.
>
>> How do I know which instance I am contacting?
>
> you don't.
> that is the nature of send. you do not know who is listening.
> (but of course you know that)
>
>> And then, why is [namecanvas] marked as obsolete?
>
> well, i keep asking this question since several years. (since i first  
> discovered that [namecanvas] is marked obsolete.

Funny these two came in the same email.  I was wondering what  
[namecanvas] provides beyond the automatically declared  
canvas-receiver.  [namecanvas] would allow you to easily send messages  
to instances of an abstraction using [namecanvas $0-canvas].  Then you  
have to track $0 for each instance so you know what's what.

That's enough of a reason to keep [namecanvas] around.


.hc

________________________________________________________________________ 
____

Using ReBirth is like trying to play an 808 with a long stick.
                                               -David Zicarelli