On Thu, 22 Jun 2006, Conor J Curran wrote:
> the objects with a prefix (like "foo/bar") which
also prevents you from importing the wrong object.
I'm lost there. What do you mean by that explicitly. Sorry Linux newbie here...
Thats ok, the concept is not very well documented, and it might look complex, but it is easy to use. It is not linux specific, but works on every platform.
Pd looks for its externals in a path, which by default includes the "extra" directory which is in your pd installation.
This way, if you instantiate an object called, lets say "lowpass", pd checks if there is an object "lowpass" in several places (built-in object, abstraction and as external). It does this by concatenating the path, the object name and some extension (.pd_linux, .dll or .pd_darwin).
Imagine you have an external in /usr/lib/pd/extra/ggee/lowpass.pd_linux (for linux in this example)
Now, if you write in your object box "ggee/lowpass", what pd does is looking for and object called "ggee/lowpass", which it finds by concatenating "/usr/lib/pd/extra/" and "ggee/lowpass" and ".pd_linux".
The same for windows, just that the extension will be ".dll".
Now, in your patch you can use "ggee/lowpass" just as if you would have loaded the "lowpass" external, but with an unambiguous name.
Therefore, at the same time you can use other objects with the same name, but from a different sub directory, like "something/lowpass". You can also call and use an abstraction called only "lowpass", because now it is different from ggee/lowpass.
Because of the fact that I have explained this several times already on the list, the concept is know as "geiger namespaces", which I think is the wrong name. This concept was introduced by Miller, but not very well documented. I found it by looking at the phase locked vocoder examples.
Hope this makes it clear,
Günter