----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Roman Haefeli reduzent@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:
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