On 11/13/24 22:02, Christof Ressi wrote:
i just wondered: probably a better approach than PR1766 would be to just expose an API (aka: message to Pd) to call the load_plugin_script on the GUI side.
If this is supposed to be used by externals, we should probably also add an API function.
i don't really see why we cannot consider sending a message to a global receiver to be part of the API, at least for procedures that do not return anything.
in the worst case (of an older Pd version that does not yet have the given message), Pd just spits out an error ("unknown message"). if instead we bake it into a proper C function call, then an older Pd version will simply refuse to load the external that "naively" uses the function (without checking whether the function actually exists).
the bonus of a C API function, is that it is easier discoverable by the casual developer (by just skimming through the public headers).
(but API documentation in Pd is an entirely different problem)
(for an abstraction it is easy enough to get its own path, e.g. with [file patchpath]; for externals it might be slightly more complicated)
Yes, for externals it's not trivial at all. Actually, it would be cool to have an API function for obtaining the current external path in the setup() function.
actually, i just found out¹ that we do have a function that can query the load path of an object class: class_gethelpdir() this is used to find the help-patch for an object (hence the name). the function was introduced in 2002, so I think you can use it without thinking of backward compatibility.
since you create your classes in the setup() callback, you can query your just created classes to get the load path of the library.
in some circumstances, the load path will be relative to the current working directory (e.g. when you load a library with a relative path from the cmdline, like "pd -lib libs/zexy"), but i think in this case it is safe to assume that the pd-gui is started from the same working directory (so relative paths resolve the same). if this is *not* the case, then I assume you have a rather complicated setup and are able to cater for this problem by yourself (e.g. by loading the library with its absolute name).
i'm a bit unhappy about the name though. should we create an alias "class_getexterndir()"? or just not worry (adding an alias seems a bit like busywork)
gmadsr IOhannes
¹ jeez; some of my more complicated externals (like Gem) have a lot of code to get the external directory; i'll have to cleanup