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/
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@ucsd.edu An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@ucsd.edu An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@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@ucsd.edu An: "Dan Wilcox" danomatika@gmail.com Cc: pd-dev pd-dev@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Christof Ressi -
Dan Wilcox -
Miller Puckette