[PD] save search path 0.43 OSX

[Jonathan Wilkes]

----- Original Message -----
> From: Mathieu Bouchard <matju at artengine.ca>
> To: Roman Haefeli <reduzent at gmail.com>
> Cc: pd-list <pd-list at iem.at>
> Sent: Monday, February 27, 2012 11:40 AM
> Subject: Re: [PD] save search path 0.43 OSX
> 
> Le 2012-02-27 à 16:44:00, Roman Haefeli a écrit :
>>  On Sun, 2012-02-26 at 11:50 -0500, Mathieu Bouchard wrote:
>>>  Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :
>>>>  On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:
>>>>>  Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :
>>>>>>  In what way [import] shouldn't be used inside 
> abstractions?
>>>>>  [import] is not very local, is it ?
>>>>  But it also works with multi-class externals. See my other mail.
>>>  But it's not very local, is it ?
>>  I got it (why are you repeating it?)
> 
> Because my point is that it doesn't import names of externals locally. So if 
> it's not local, then it doesn't really matter that it does the same (?) 
> with multi-class externals, because that's not what it should do.
> 
> Fortunately, nameclashes are a relatively rare occurrence, otherwise we'd 
> more often hear things like « restart pd in order to avoid nameclashes caused by 
> [import] being present in patches that have already been closed ».
> 
>>  [zexy/dirac~] just simply doesn't work on a Debian box that has 
> puredata and pd-zexy installed. It seems that [zexy/dirac~] adds 
> 'dirac~' to the global namespace, not 'zexy/dirac~'. At least, 
> when I create [zexy/dirac~] in a patch in Pd-extended, I can create instances of 
> [dirac~] afterwards.
> 
> So, is this a bug in Zexy, or a bug in the way «namespacing» is implemented ? 
> What does this case prove ?

Here is (maybe) a related issue:
* patch a.pd has abstraction [foo/prop_dialog]
* patch b.pd has abstraction [bar/prop_dialog]

I send "vis 1" message to pd-prop_dialog.pd and both foo/prop_dialog and bar/prop_dialog 
will pop up.  How do I vis just foo/prop_dialog?

So just use [sendcanvas] or [namecanvas] or whatever.  But let's say I've got an abstraction 
[foo/sosc~] that scales its output based on its (x,y) vicinity to other instances of itself 
in the patch.  So I broadcast a message to pd-sosc~.pd to get all the x,y positions, but this 
will send to bar/sosc~, too.

Sorry for the obscure example, but I think it's important for abstractions to have some way 
of accessing "class-wide" data-- like this:

[receive pd-someabstraction.pd]
|
[route echo]
|
[route our_shared_float]
|
| [42, bang(  <-- let's change and tell all our siblings the shared float
|/
[v $0-count]
|
[prepend echo our_shared_float]
|
[list trim]
|
[send pd-someabstraction.pd]

All abstraction can now get the shared float to [v $0-count], but we'll be leaking it 
to any other abstraction in the global namespace that happens to have the name we 
gave to our abstraction.  Registering the abstraction's name as pd-foo/someabstraction.pd 
would fix this, but I'm not sure what side effects this would cause.

-Jonathan

> 
> ______________________________________________________________________
> | 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
>