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. _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
