[PD-dev] remove tk scaling

Hans-Christoph Steiner hans at at.or.at
Thu Jun 20 05:14:31 CEST 2013


On 06/19/2013 04:38 PM, Miller Puckette wrote:
> [discussion of tk scaling deleted...]
> 
>> What do you gain by removing in?  I think we really need to stop wasting time
>> on little details like this, and instead work towards real fixes.  Does anyone
>> object to the idea of truly separating the GUI from the core?  I haven't heard
>> them.
>>
>> .hc
>>
> I already gained something... I can read the Pd console output now :)

You can also just change the console font size with the font panel for
temporary changes, or set the console font size if you want it permanent.  If
that's not in Pd-vanilla, feel free to take it from Pd-extended.  tk scaling
is not the way to set font sizes.  Setting the font size is the way to do that.


> 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



More information about the Pd-dev mailing list