[PD-dev] "library" class names loading depth "1000" reached

Jonathan Wilkes jancsika at yahoo.com
Tue Apr 28 15:07:37 CEST 2015

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 at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150428/15bf582c/attachment.html>

More information about the Pd-dev mailing list