----- Original Message -----
> From: Mathieu Bouchard <ma...@artengine.ca>
> To: Roman Haefeli <reduz...@gmail.com>
> Cc: pd-list <pd-list@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@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list