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
On 2015-04-28 10:27, Jamie Bullock wrote:
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”) …
not in my book¹. which sources are you using (for this specific example)?
fgamsdr IOhannes
¹ https://svn.code.sf.net/p/pure-data/svn/trunk/externals/iemlib/iemlib1/src/s...
On 28 April 2015 at 09:56:45, IOhannes m zmoelnig (zmoelnig@iem.at) wrote:
On 2015-04-28 10:27, Jamie Bullock wrote:
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”) …
not in my book¹. which sources are you using (for this specific example)?
Oops… this is embarrassing...
It seems that someone changed the symbol in *our* repository to “fix” the externals to work with libPd. https://github.com/BirminghamConservatoire/IntegraLive/commit/e5f8026f5ebf45...
…which of course broke our Module creator, which uses Pd.
But of course the proper fix is to use [declare -stdpath] in the patch so just the object name can be used everywhere.
Sorry for the noise.
Jamie
On 04/28/2015 04:27 AM, Jamie Bullock wrote:
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”.
I'm looking at the source files for those externals in Pd-l2ork, and I don't see the libname prefixed in the class_new call.
Are you talking about the code in class_new from m_class.c?
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 http://twitter.com/jamiebullock
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig -
Jamie Bullock -
Jonathan Wilkes