[PD-dev] [pdcontrol] reliance on Tcl

Miller Puckette msp at ucsd.edu
Wed Aug 7 17:57:25 CEST 2019


I think you're right about this - "gui" will also fail if running Pd
-nogui :)  The only functionality I can see as really important is the
"system" one.  That itself is going to be necessarily system-dependent and
thus non-portable.

And yes, Christof's suggestion to make a real API is excellent - if that
comes about, and if I've replaced "gui" with something like "system" in
the pdcontrol object, it will be easy to reimplement it on top of the new
API later.

cheers
M

On Wed, Aug 07, 2019 at 03:34:46PM +0200, Dan Wilcox wrote:
> 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.
> 
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> 
> 
> 

> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev






More information about the Pd-dev mailing list