Hi,
Is it possible to have a Tcl extension load from an abstraction directory or -declare path (when the abstraction loads) instead of the top level Pd search path? In other words I want to put something-plugin.tcl into a folder that is not on the search path and have it load when I load the patch or abstraction in the folder where it is. I guess the ultimate use-case is plugins that only load with a particular abstraction.
Cheers,
Chris.
You can do [loadbang] -> [source some-plugin.tcl( -> [hcs/sys_gui]. Not the most elegant method but it works. Seems like a job for [declare].
On Wed, Nov 13, 2024 at 1:50 AM Chris McCormick chris@mccormick.cx wrote:
Hi,
Is it possible to have a Tcl extension load from an abstraction directory or -declare path (when the abstraction loads) instead of the top level Pd search path? In other words I want to put something-plugin.tcl into a folder that is not on the search path and have it load when I load the patch or abstraction in the folder where it is. I guess the ultimate use-case is plugins that only load with a particular abstraction.
Cheers,
Chris.
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/5M7WHO3PZA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
And you can maybe use plugin-dispatch-receiver for a vanilla solution, something like:
[loadbang] | [plugin-dispatch start-plugin args | [s pd]
then in the plugin itself
proc start-plugin (args) { source this-plugin.tcl }
On Wed, Nov 13, 2024 at 1:55 AM adam johnson ulioidle@gmail.com wrote:
You can do [loadbang] -> [source some-plugin.tcl( -> [hcs/sys_gui]. Not the most elegant method but it works. Seems like a job for [declare].
On Wed, Nov 13, 2024 at 1:50 AM Chris McCormick chris@mccormick.cx wrote:
Hi,
Is it possible to have a Tcl extension load from an abstraction directory or -declare path (when the abstraction loads) instead of the top level Pd search path? In other words I want to put something-plugin.tcl into a folder that is not on the search path and have it load when I load the patch or abstraction in the folder where it is. I guess the ultimate use-case is plugins that only load with a particular abstraction.
Cheers,
Chris.
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/5M7WHO3PZA...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
On 11/13/24 09:21, adam johnson wrote:
And you can maybe use plugin-dispatch-receiver for a vanilla solution, something like:
[loadbang] | [plugin-dispatch start-plugin args | [s pd]
then in the plugin itself
proc start-plugin (args) { source this-plugin.tcl }
that looks like a hen-egg problem. in order to be able to call "plugin-dispatch", the gui-plugin has to register with the plugin-dispatcher... and in order to do that, it has to be loaded first (in which case you've already solved the problem).
or to put differently: "plugin-dispatch" is not a way to send arbitrary commands to the GUI.
also note that you probably shouldn't "source" the tcl-code directly, but instead use the 'load_plugin_script' proc (which adds some safety around the actual sourcing)
gmasdr IOhannes
that looks like a hen-egg problem.
I did not quite think that through, would need a dedicated script for loading any scripts the abstractions want and almost certainly want to check that the script is not already loaded, but load_plugin_script handles the latter for you. Thanks for pointing me to that proc.
or to put differently: "plugin-dispatch" is not a way to send arbitrary commands to the GUI.
Could you elaborate on why not? All I can come up with is that it breaks order of operations but so does [sys_gui] and we can work around that in the same way [sys_gui] does if need be. Are my patches/abstractions which use plugin-dispatch this way going to blow up in my face when the stars align?
On 11/13/24 22:10, adam johnson wrote:
or to put differently: "plugin-dispatch" is not a way to send arbitrary commands to the GUI.
Could you elaborate on why not? All I can come up with is that it breaks order of operations but so does [sys_gui] and we can work around that in the same way [sys_gui] does if need be. Are my patches/abstractions which use plugin-dispatch this way going to blow up in my face when the stars align?
i don't know how you use it, but:
"plugin-dispatch" has a very clear scope: it is a way to interact with a GUI-plugin from your patch. it is decidedly *not* a way to interact with the Tcl/Tk interpreter (that happens to host the GUI plugin).
the workflow is:
- the GUI loads a plugin
- the plugin registers a new method (along with a name) with the
dispatcher, using the ::pd_connect::register_plugin_dispatch_receiver proc
- from the Pd-patch you can now call the registered method (by the name
it used to register the method)
the plugin is of course free to do whatever it likes to do with the received data, so it could provide a low-level interface to the Tcl/Tk interpreter.
i hope this clears things up.
gasdmnr IOhannes
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.
Christof
On 13.11.2024 08:50, Chris McCormick wrote:
Hi,
Is it possible to have a Tcl extension load from an abstraction directory or -declare path (when the abstraction loads) instead of the top level Pd search path? In other words I want to put something-plugin.tcl into a folder that is not on the search path and have it load when I load the patch or abstraction in the folder where it is. I guess the ultimate use-case is plugins that only load with a particular abstraction.
Cheers,
Chris.
-
adam johnson -
Chris McCormick -
Christof Ressi -
IOhannes m zmoelnig