On Tue, 2009-05-26 at 09:07 +0200, IOhannes m zmoelnig wrote:
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.
Yeah, that's what I think, knowing what little I do about the pd and pd-gui interaction.
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.(?!)
Ahh, here's the point.  You assume that people like me would know ahead of time not use those
"stupid, hacky" gui objects with slow machines.  As I said before, I assumed that -nogui meant "no gui"
and that optimizations were in place to basically ignore the gui elements when run in -nogui mode.  This assumption lead me to create an easy to use gui environment which facilitates my style of patching but is now biting me in the ass.  I guess I should have RTFM, oh wait, where does it talk about this issue?

So your suggestion is to scrap all of this and use minimal objects again?  What is this? 1999?

Forgive me for assuming pd is as awesome as I had hoped it would be.
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.
This is too bad ... so why are they even in pd?  I see most people creating great GOP abstraction etc on what is essentially a hack more or less?  I would probably be using Max by now if I didn't have the requirement of running my system on an essentially embedded device, which Max will never be able to do.  Don't get me wrong, I really like using pd, but I'm not married to it.

Heaven forbid pd becomes more usable to public at large.

I suppose I can't bitch because with open source, I "get what I pay for".  I am, however, willing to work on this.  Here's an email I tried to send to pd-dev, but I don't really feel like adding a new mailing list so I'll quote it here:

There are issues I have with pd (GOP/GUI slowness, -nogui slowness, etc) and I'm wondering if there are any residencies/places to apply to work on pd.  I know C/C++ but I have not, at this time, really looked into the source very much as I know I just do not have the time to do anything meaningful on the side.

I have no intention of rewriting pd etc, I'm mainly interested in gui optimizations so that I can run GOP patches on my wearable without the damn vus and number boxes killing the cpu.

Yeah yeah, I'm probably full of shit for saying the same old things about the same old problems, but I would very much like to try solving some of them.  One of the reasons I use pd, is that I can see myself using my gear for a long time into the future.

---
Dan Wilcox
danomatika.com
robotcowboy.com