[PD] Slow cpu/RJDJ patching approach ...

[danomatika]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090526/a5c1b57d/attachment.htm>