[PD] libpd separating gui from core

[Lorenzo Sutton]

On 13/01/2014 15:32, Dan Wilcox wrote:
> As Hans has proposed for years, IMO this is really the only way to
> perhaps solve the "PD gui development doesn't move fast enough" problem
> in the long term. In this case, Miller would have the core (in libpd) &
> the pd-vanilla wrapper gui formally separated while everyone else can
> then use the same libpd core within other flavors. The DSP core is the
> heart and soul and I see no reason to try and change that in any way.

Personally I have mixed feelings about that. On the one hand the strong 
paradigm and attractiveness of Pd has always been the dataflow concept, 
and that is definitely related (and needs) some sort of GUI. Now 
personally I've never been concerned too much about the aesthetics of 
the gui as long as it enables me to make noise and supports me in 
experimenting with it. Nor have I ever really envied the aesthetics of 
other proprietary dataflow platforms which in the end are non-standard, 
non-native anyway..

Indeed I think in an environment like Pd, GUI has actually two aspects: 
dataflow (i.e. 'programming' with Pd) and control. Clearly the 
distinction is never clear-cut.
For control I think the best solution would be to look at using external 
libraries (environments) which can communicate with Pd (gtk, Qt, html5, 
arduino, ...). There is already stuff in place like TCP, OSC, but I'm 
not sure it's the most friendly. Maybe Pd should have the option to 
expose a 'server' by default for easily doing the equivalent of a [send] 
or something like that without need for additional overhead? Isn't this 
even more relevant as people are seriously starting to experiment on 
Raspberry Pi and similar environments?

Just some brainstorming thoughts :)

Lorenzo.