moved this to pd-dev, as it is now more about implementing...
On 13/11/2024 12:46, Christof Ressi wrote:
Hi,
I think this PR would be a first step in this direction: https:// github.com/pure-data/pure-data/pull/1766
So far it only allows to load GUI plugins together with compiled externals, but I guess the mechanism can be extended to specifically load GUI plugins.
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. e.g. [; pd load-gui-plugin /path/to/my/plugin( which would then tell the GUI to load /path/to/my/plugin.tcl
notes: - this takes the full path, so the GUI doesn't need to know anything about the filesystem organization (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) - i deliberately left out the file-extension (so it also works when we just motif is the GUI backend)
as opposed to PR1766, this moves the responsibility to loading a GUI-plugin from Pd itself to the object/library that wants to use the GUI-plugin. given that an object/library will typically know whether it wants to load a GUI-plugin this is not exactly a bad thing.
gmdsar IOhannes
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.
(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.
Christof
On 13.11.2024 17:47, IOhannes m zmölnig wrote:
moved this to pd-dev, as it is now more about implementing...
On 13/11/2024 12:46, Christof Ressi wrote:
Hi,
I think this PR would be a first step in this direction: https:// github.com/pure-data/pure-data/pull/1766
So far it only allows to load GUI plugins together with compiled externals, but I guess the mechanism can be extended to specifically load GUI plugins.
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. e.g. [; pd load-gui-plugin /path/to/my/plugin( which would then tell the GUI to load /path/to/my/plugin.tcl
notes:
- this takes the full path, so the GUI doesn't need to know anything
about the filesystem organization (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)
- i deliberately left out the file-extension (so it also works when we
just motif is the GUI backend)
as opposed to PR1766, this moves the responsibility to loading a GUI-plugin from Pd itself to the object/library that wants to use the GUI-plugin. given that an object/library will typically know whether it wants to load a GUI-plugin this is not exactly a bad thing.
gmdsar IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/5NBI7555BI7...
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
On 14.11.2024 09:40, IOhannes m zmoelnig wrote:
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.
Because this is not idiomatic. I really don't want to assemble a Pd message just to make an API call. Do you know of any other API that is *only* accessible through a Pd message?
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").
You just hit another downside of Pd messages: no opportunity for error handling
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).
That's why we now have sys_getfunbyname() :)
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
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/4RIKAADGG2L...
On 11/14/24 13:45, Christof Ressi wrote:
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.
Because this is not idiomatic. I really don't want to assemble a Pd message just to make an API call. Do you know of any other API that is *only* accessible through a Pd message?
tuning dsp on/off? fast-forwarding?
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").
You just hit another downside of Pd messages: no opportunity for error handling
and in this case, we don't even need error handling. we can do a runtime check of the Pd version and don't trigger an error in the first place.
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).
That's why we now have sys_getfunbyname() :)
yes. but with Pd I prefer to be very conservative. so I'll wait a couple of years to make sure that practically all installations of Pd that might use my externals do have the sys_getfunbyname()
mgfdr IOhannes
On 11/14/24 13:56, IOhannes m zmoelnig wrote:
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.
Because this is not idiomatic. I really don't want to assemble a Pd message just to make an API call.
and on re-thinking, you can of course just use send messages directly to the GUI:
```C pdgui_vmess("load_plugin", "ss", "helloworld-plugin", class_gethelpdir(helloworld_class)); ```
You just hit another downside of Pd messages: no opportunity for error handling
and come to think of it: in this specific case (loading GUI-plugins), there's no way to do error checking anyhow, as the actual loading is done asynchronously in a different process.
i'm not proposing to replace all C API calls with Pd messages. i'm not even suggesting that /in the future/ we should strive to use Pd messages rather than C function calls.
i just think the Pd message is an appropriately simple solution that can be used by both abstractions and externals.
ghmadsf IOhannes
On 14.11.2024 14:05, IOhannes m zmoelnig wrote:
On 11/14/24 13:56, IOhannes m zmoelnig wrote:
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.
Because this is not idiomatic. I really don't want to assemble a Pd message just to make an API call.
and on re-thinking, you can of course just use send messages directly to the GUI:
pdgui_vmess("load_plugin", "ss", "helloworld-plugin", class_gethelpdir(helloworld_class));
That would be better because at least it's now clear that it's a GUI message and we could have a place to document all GUI commands.
You just hit another downside of Pd messages: no opportunity for error handling
and come to think of it: in this specific case (loading GUI-plugins), there's no way to do error checking anyhow, as the actual loading is done asynchronously in a different process.
i'm not proposing to replace all C API calls with Pd messages. i'm not even suggesting that /in the future/ we should strive to use Pd messages rather than C function calls.
i just think the Pd message is an appropriately simple solution that can be used by both abstractions and externals.
And I think we shouldn't even start with it because IMO it would create an awkward split in the API (C functions vs. Pd messages)
ghmadsf IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/DRA6TX5PXVF...
On 14.11.2024 13:56, IOhannes m zmoelnig wrote:
On 11/14/24 13:45, Christof Ressi wrote:
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.
Because this is not idiomatic. I really don't want to assemble a Pd message just to make an API call. Do you know of any other API that is *only* accessible through a Pd message?
tuning dsp on/off?
canvas_suspend_dsp() + canvas_resume_dsp()
fast-forwarding?
I'd argue this is a patch level feature and not part of the external API.
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").
You just hit another downside of Pd messages: no opportunity for error handling
and in this case, we don't even need error handling. we can do a runtime check of the Pd version and don't trigger an error in the first place.
It's a general downside with this approach, so let's better not start it. That being said, I do see a chance for error checking: Pd could check if a suitable extension file exists for the current GUI backend and return failure otherwise.
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).
That's why we now have sys_getfunbyname() :)
yes. but with Pd I prefer to be very conservative. so I'll wait a couple of years to make sure that practically all installations of Pd that might use my externals do have the sys_getfunbyname()
Well, by that logic we can't introduce any new API functions. Or do you want to make all new API functions only available as Pd messages for the next 10 years? I hope not...
mgfdr IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/LGCJGQIITWE...
On 11/14/24 09:40, IOhannes m zmoelnig wrote:
the function was introduced in 2002, so I think you can use it without thinking of backward compatibility.
on re-checking i noticed, that class_gethelpdir() has been introduced in 2002, *but* has been made publicly available (in m_pd.h) much later in 2013 (22b17b26fe66acf349d49668589e1371386f7347), aka Pd-0.45
i guess it is still safe to assume that the function can be used without caring too much about backwards compatibility.
fgmdasrt IOhannes
-
Christof Ressi -
IOhannes m zmoelnig -
IOhannes m zmölnig