[PD] save search path 0.43 OSX
Jonathan Wilkes
jancsika at yahoo.com
Sat Mar 3 23:49:34 CET 2012
----- Original Message -----
> From: Mathieu Bouchard <matju at artengine.ca>
> To: IOhannes m zmoelnig <zmoelnig at iem.at>
> Cc: pd-list <pd-list at iem.at>
> Sent: Saturday, March 3, 2012 3:36 PM
> Subject: Re: [PD] save search path 0.43 OSX
>
> Le 2012-02-27 à 18:31:00, IOhannes m zmoelnig a écrit :
>> On 2012-02-27 18:22, Jonathan Wilkes wrote:
>>> Sorry for the obscure example, but I think it's important for
> abstractions to have some way
>>> of accessing "class-wide" data-- like this:
>> you mean something like [1]?
>> [1]
>>
> https://sourceforge.net/tracker/?func=detail&aid=1403917&group_id=55736&atid=478072
>
> It's related, but the need is for something that doesn't depend on the
> way it's written : if [import shadok] then [shadok/gibi] and [gibi] might be
> the same, but will use different receive-symbols.
>
> But more importantly, what you suggest is for accessing all canvas-objects that
> are of a same abstraction-class, which is not the same as sharing various
> properties that belong to a certain abstraction-class.
I think I have a different solution which doesn't need an "echo" method for canvases.
To send globally to _this_ abstraction, just concatenate the directory it lives in with
the filename.
To send to all instances on the parent canvas, just send to the above prefixed with
the parent $0.
To send to all instances anywhere up to the toplevel, just send to toplevel $0 plus
dir plus filename.
However, if you are in the parent patch and you want to send to all the abstractions
that are children of the parent patch (non-locally), pd-foo/bar.pd seems like the only
way to do that.
>
> I mean that the canvas-object used to make an abstraction-object is not the same
> as the abstraction-object itself. The canvas-object does not directly handle
> stuff that is implemented in pd, and its receive-symbols are really about
> canvas-responsibilities.
>
> So if an abstraction pretends to be a canvas using [receive] in an attempt to
> extend the list of methods that the object supports, then every message not
> meant for the canvas will cause « canvas: no such method ».
Right, that's what the "echo" method is about.
>
> An abstraction-object's canvas object, even though it represents the object
> itself, usually shouldn't be talked to directly from outside, as the
> abstraction-class is what is supposed to know whether and how 'vis',
> 'coords', etc., should be used.
My alternative method outlined above avoids this.
>
> ______________________________________________________________________
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list