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" <[email protected]> > > An: "Dan Wilcox" <[email protected]> > > Cc: pd-dev <[email protected]> > > 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 > > > [email protected] > > > https://lists.puredata.info/listinfo/pd-dev > > > > > > > > > > _______________________________________________ > > Pd-dev mailing list > > [email protected] > > https://lists.puredata.info/listinfo/pd-dev > > _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
