Yeah, that's what I think, knowing what little I do about the pd and pd-gui interaction.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.
Ahh, here's the point. You assume that people like me would know ahead of time not use thosehaving 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.(?!)
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.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.
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.
--- Dan Wilcox danomatika.com robotcowboy.com |