[PD-dev] [pdcontrol] reliance on Tcl

[Christof Ressi]

Alright, good to know! I might just go ahead and do it anyway because I have some spare time ATM :-)

Christof

> Gesendet: Mittwoch, 07. August 2019 um 18:20 Uhr
> Von: "Miller Puckette" <msp at ucsd.edu>
> An: "Christof Ressi" <christof.ressi at gmx.at>
> Cc: pd-dev <pd-dev at lists.iem.at>
> Betreff: Re: Re: [PD-dev] [pdcontrol] reliance on Tcl
>
> All good, but I need to freeze 0.50 if it's going to come out in August -
> I think I need to stick to bug fixes now.
>
> (One of which is "portaudio: handle closing of audio device because of
> sys_pollgui()" from PR 710 - but I think the rest of that PR can wait til
> afterward as things are at least in a better state than they were before ATM).
>
> cheers
> M
>
> On Wed, Aug 07, 2019 at 06:15:03PM +0200, Christof Ressi wrote:
> > Cool, I'll try to setup a working prototype in the next few days.
> >
> > Christof
> >
> > > Gesendet: Mittwoch, 07. August 2019 um 17:57 Uhr
> > > Von: "Miller Puckette" <msp at ucsd.edu>
> > > An: "Dan Wilcox" <danomatika at gmail.com>
> > > Cc: pd-dev <pd-dev at lists.iem.at>
> > > Betreff: Re: [PD-dev] [pdcontrol] reliance on Tcl
> > >
> > > 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
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Pd-dev mailing list
> > > Pd-dev at lists.iem.at
> > > https://lists.puredata.info/listinfo/pd-dev
> > >
>