I'm just now looking into the new [pdcontrol] object and I like what I see. I am concerned about the gui sending feature as it seems to rely directly on Tcl.

With my libpd hat on, I'm interested in moving the pd core towards less/no direct reliance on raw sending Tcl/Tk strings, basically making Pd more GUI agnostic. For the gui running Tcl/Tk, the plugin concept makes sense as it's focused on that domain and not with the pd core. However for a future libpd-based app that renders patches with a different framework on a specific platform (ie. PdParty) and focused on as much feature parity as possible, I may need to suddenly support people's edge-case usage of raw Tcl without a Tcl interpreter.

If the idea is that gui sending provides a quick way to emulate a system() call, I can understand that however I think a more universal design would be based around system() itself and an overridable function or interface as some platforms, namely iOS, do not allow the use of system().

I bring this up now as once this precedent is set, it's obviously *very* difficult to change it once people start using this feature.