I noticed that a few externals I’ve been working with won’t load in Pd unless
they are inside a folder with a specific name.
For example:
bsaylor/partconv~
iemlib/soundfile_info
If soundfile_info is in a folder called “iemlib’ which is in Pd’s search path
then typing “iemlib/soundfile_info” in an object box loads the external
If soundfile_info is in Pd’s path but not in the “iemlib” folder, then Pd
attempts to load the external but fails with:
soundfile_info: already loaded
...
soundfile_info: already loaded
maximum object loading depth 1000 reached
soundfile_info
... couldn't create
Looking at the source code for these externals (and I guess this is a wider
design pattern?), I notice that class constructor is bound to a symbol of the
form “<folder>/<object>”, e.g. class_new(gensym("iemlib/soundfile_info”) …
Hence, if I type “soundfile_info” in an object box, even though Pd can find the
external, it can’t actually create an instance of it because the symbol
“soundfile_info” can’t be found. The object’s name is actually
“iemlib/soundfile_info”.
What is the purpose of this design? It breaks the idea that “an external” is a
file that can placed anywhere in Pd’s path...
Is it something to do with libPd compatibility? Will such externals work in
libPd e.g. if a patch has “iemlib/soundfile_info” and soundfile_info is
compiled into the Pd binary, is this a measure to ensure that libPd finds the
object?
Thanks,
Jamie
--
http://jamiebullock.com
@jamiebullock_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
