[PD-dev] remove tk scaling

Miller Puckette msp at ucsd.edu
Thu Jun 20 17:24:57 CEST 2013


> 
> > 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



More information about the Pd-dev mailing list