> > > Anyhow, if by separating the GUI from the core you mean re-writing the Pd > > patch > > editor in Tcl/TK, I think that would create enormous headaches. i enjoyed > > some of those with Max/FTS (in which the GUI layer was responsible for > > editing) and Pd's separation of duties is partly a reaction from that > > experience. But now there's even a stronger reason - since the GUI is > > now written in a scripting language it is likely to be very hard to get it > > to the level of robustness and performance needed in an editor. > > > > But perhaps you mean something else, such as putting an abstract layer > > between > > Pd 'proper' and the Tcl/TK code. That might be feasible although I think > > it would still be quite a pain. > > > > OTOH I recently talked with Peter Brinkmann about the idea of making an API > > for 'graphics updates' (changing float and table values) so that > > non-GUI-users > > could have an easier time seeing patch state. This seems a manageable first > > step... > > > > cheers > > Miller > > > > There are many python based GUIs that perform orders of magnitude better than > Pd when it comes to screen drawing performance. Max/FTS was 20+ years ago, > scripting languages have come a long way since then. The current situation > guarantees crappy performance because it forces things to be implemented in a > way that avoids graphics optimizations. In Pd's current architecture, things > need to be handled incrementily and over a network socket. In any decent > graphics programming environment, updates can be handled en masse. > > .hc
I was trying to make 2 separate argments... First I think it's a miserable experience makeing an editor in one process for complex data structures that are needed by a different process (the experience I learned from Max/FTS). Second, even if one were to try it, I don't think any scripting language from 1993 or 2050 will be up to it. I could be wrong on the latter point but I'm pretty sure I'm right on the former. I think we're converging on the concludion that 'th scaling 1' is appropriate for Pd extended (where taking the line out could break unknown hundreds of third-party objects/features/plug-ins) but inapprorpriate for vanilla where I still fail to see any problems from taking it out - although I've only tried it in a couple of environments so far. cheers Miller _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
