On May 26, 2009, at 3:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I've recently been working with 80MHz machines that don't even have
FPUs, so I also care about oooold machines. (These little
computers are known as "iPods"). One thing that is definitely worth trying is to update to the
latest version of Tcl/Tk. They have done a lot of optimization in
8.5, I think on X11 too. Another thing to try is writing the GUI in a toolkit that is
optimized for speed. I don't know if you have a GPU, but if you
wrote Pd GUI objects using something like togl or tkzinc, both use
OpenGL, that could also help. http://togl.sourceforge.net/ http://www.tkzinc.org/i am still pretty convinced that tcl/tk is not the buster, so
replacing it by someting more performant will only give you little
help. the problem comes from how Pd(-core) communicates with the Pd-gui;
and that Pd(-core) needs a lot of calculation power to make Pd-gui
draw something nicely. unless this calculations are done on the Pd- gui side, i see little chances that things will improve.having said all that, i honestly do not understand how the matter of
CPU-hungry gop objects impose any problems on slow machines. you are
surely not saying, that you develop your patches for iPod/wearables/ P-100 andwhatelse with graphical objects.(?!)personally i cannot imagine developing cpu-intensive patches on my
current machine, which is a by-now-rather-oldish amd64 x2 dual-core
(well, Pd cannot use more than 1 core anyhow) 4200+, with GOP enabled.
Yeah, I agree that the communications are a big part of it. Part of
writing a custom GUI would be to write a simple communications to suit
the needs at hand.
But I think that the slowness in Pd's GUI is not even that much due to
communications, but rather how the code is structured. For example,
if you move on element in an array, instead of issuing a single Tk
'move' command, Pd deletes the whole array, then recreates it.
And Dan, I also share your frustration with the common attitude on
this list of "it is what it is". That's why I am working on re-
writing the Pd GUI from scratch in pure Tcl with the aim of making it
use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4). I
think you should join the project. Instead of venting via email, vent
via code.
As for replacing Pd with SuperCollider or C/rtaudio, are you sure that
those are any more efficient? Pd does have its problems, but audio
synthesis is pretty solid in Pd. For example, reactable still uses Pd
as its synth engine.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne