Hi All,
In figuring out why seqdemo.pd did not work (in the cool faust/tools/faust2pd/examples distribution), I discovered that the local file ./seq.pd was being shadowed by /usr/lib/pd/extra/cyclone/seq.pd_linux. It appears that, due to search order, all externals, wherever they may reside in the search path, take precedence over .pd files, even those in the current working directory. It seems to me both externals and subpatches in the cwd should take precedence over the rest of the search path. Also, I would expect subpatches to take precedence over externals in the same directory (with a warning about the shadowing printed to the console).
My workaround, by the way, was to rename seq.pd to seqr. pd in the seqdemo directory.
Cheers, Julius
Hi Julius,
I think that "seq" isnät getting shadowed (the patc's directory is always searched first) but rather, that once an extern is loaded of a certain name, Pd no longer searches for abstractions of the same name. It's as if you tried to name an abstraction "float" or something -- C objects, internal or external, essentially become keywords.
A possible workaround would be not to load the library containing seq (and in general, perhaps it's best not to load any that you aren't actively using).
There should be some way in Pd to throw out objects by name... I'�m still trying to figure out how to deal with name conflicts so that nobody ever gets burned :)
cheers Miller
On Fri, Aug 31, 2007 at 12:09:13PM -0700, Julius Smith wrote:
Hi All,
In figuring out why seqdemo.pd did not work (in the cool faust/tools/faust2pd/examples distribution), I discovered that the local file ./seq.pd was being shadowed by /usr/lib/pd/extra/cyclone/seq.pd_linux. It appears that, due to search order, all externals, wherever they may reside in the search path, take precedence over .pd files, even those in the current working directory. It seems to me both externals and subpatches in the cwd should take precedence over the rest of the search path. Also, I would expect subpatches to take precedence over externals in the same directory (with a warning about the shadowing printed to the console).
My workaround, by the way, was to rename seq.pd to seqr. pd in the seqdemo directory.
Cheers, Julius
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There should be some way in Pd to throw out objects by name... I'm still trying to figure out how to deal with name conflicts so that nobody ever gets burned :)
In a way it might be nice to have some concept of "namespaces", such that objects can be referred to simply by name, or alternatively by prefixing their namespace.
You could refer to the object "seq", hoping that it is the only one available, but a more diligent programmer might be able to refer to the same object as "hammer.seq", or "cyclone.seq". (Perhaps the C++ "::" operator might be better so as to avoid conflicts with file extensions.) I suppose though that you can already do something like this by using paths creatively, but having the namespace information embedded in the actual object instead of relying on directory structures might also be useful.
For abstractions, the main Pd patch could include an object called "namespace" that specifies the namespace information for that abstraction?
I guess a downside is that in both cases, the object would have to be loaded before being able to identify whether or not it matches the given namespace.
I'm not sure if this has been previously suggested, so I apologize if I'm repeating an old problem..
Steve
This is addressed in the Pd-extended distribution. Every library is
compiled so that each class is compiled as it's own file (i.e.
[counter] = counter.pd_linux) instead of having multiple classes in
one file.
Functional namespaces already exist in Pd. This feature is used
extensively in Pd-extended. It's based on directory names, then
the / is the separator. The 'libdir' format allows a directory of
objects to act like a library.
There has been quite a bit of discussion about this topic over the
years, search the archive if you are interested.
.hc
On Aug 31, 2007, at 3:09 PM, Julius Smith wrote:
Hi All,
In figuring out why seqdemo.pd did not work (in the cool faust/tools/faust2pd/examples distribution), I discovered that the
local file ./seq.pd was being shadowed by /usr/lib/pd/extra/cyclone/seq.pd_linux. It appears that, due to search order, all externals, wherever they may reside in the search path, take precedence over .pd files, even those in the current
working directory. It seems to me both externals and subpatches in the cwd should take precedence over the rest of the search path. Also, I would expect subpatches to take precedence over externals in the same directory (with a warning about the shadowing printed to the console).My workaround, by the way, was to rename seq.pd to seqr. pd in the seqdemo directory.
Cheers, Julius
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
-
Hans-Christoph Steiner -
Julius Smith -
Miller Puckette -
Stephen Sinclair