Hi,
Zitat von Josh Steiner josh@vitriolix.com:
there are some really great advantages to the PD gui being done in a scripting language (take look at Krzysztof widget/tot/toy if you havnt already).
I don't understand tcl ... ^_^ The jMax crew is going an alternative approach. Because of license issues with Java/Swing, there is work going on to port the GUI side to Python with a yet undecided toolkit, probably wxPy I guess. This could in the end open up GUI scriptability while still having a fast (enough) GUI. I don't think, that Tk is much too slow for Pd, but there are issues with the GUI disturbing the DSP chain, and that is really bad. I don't understand the exact reason for this (I would like to) but if I understand what was said about this here correctly it has to do with the protocol that Pd uses to communicate between the audio engine and the GUI.
With a proper design, in the end it should be possible to embed any decent scripting language to also control GUI elements.
Miller Puckette wrote:
On that subject, I'm thinking about (someday) rewriting Pd's whole graphics layer, probably in "wx", to make it faster. I'm hoping not to have to do that until I understand how the whole GUI should work better than I do now.
This is great to hear. As it is currently, Pd is very useable IMO. But with the introduction of advanced GUI options (graph-on-parent, data structures) people will build more GUI heavy patches, and that must not disturb the audio chain.
ciao
Frank Barknecht _ ___footils.org_