i just did an (unrelated) codesearch over the externals uploaded on deken, and i noticed, that flucoma is defining a Tcl-proceduure pd:
|
sys_vgui(" proc pd {args} {pdsend [join $args \" \"]}\n"); |
this sounds like very bad practice.
I would assume that Pd-GUI is the owner of ::pd, rather than some random external.
so, please pretty please make sure that all procedures, global variables and whatever you can think of live in a designated namespace on the GUI side:
namespace eval ::FluidCorpusManipulation:: { }
proc ::FluidCorpusManipulation::pd {
#...
}(also I would suggest to put all your Tcl code into a separate file (e.g. FluidCorpusManipulation-plugin.tcl) and just have a single line in the Pd-core to load this file (on the GUI side), rather than abusing sys_vgui() to dump the code over the wire - sys_vgui() really should be treated as "private")
i just did an (unrelated) codesearch over the externals uploaded on deken, and i noticed, that flucoma is defining a Tcl-proceduure
pd:flucoma-pd/src/fluid.waveform/fluid.waveform.c
Line 1122 in 1abc591
this sounds like very bad practice.
I would assume that Pd-GUI is the owner of
::pd, rather than some random external.so, please pretty please make sure that all procedures, global variables and whatever you can think of live in a designated namespace on the GUI side:
(also I would suggest to put all your Tcl code into a separate file (e.g.
FluidCorpusManipulation-plugin.tcl) and just have a single line in the Pd-core to load this file (on the GUI side), rather than abusingsys_vgui()to dump the code over the wire -sys_vgui()really should be treated as "private")