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

danomatika danomatika at gmail.com
Tue May 26 15:04:43 CEST 2009


On Tue, 2009-05-26 at 08:33 -0400, Michal Seta wrote:

> On Tue, May 26, 2009 at 7:37 AM, danomatika <danomatika at gmail.com> wrote:
> 
> > So your suggestion is to scrap all of this and use minimal objects again?
> > What is this? 1999?
> 
> I think that, pd's inefficiencies aside, if you are developing for
> embedded devices with limited computing resources, you should always
> pretend you're in 1999.

Yes, totally right ... I just wish it weren't so!  I do manage realtime with 10ms
latency on a 500Mhz machine though which is nothing to sneeze at, but dosen't leave much room aside.

> > 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?
> 
> There was an effort once, in its latest incarnation was called Desire
> Data, to separate the gui from the core, the client from the server
> and optimize things but I think it is now in a coma.

Yeah I know ... but it seemed to be trying to reach a bit too far too quickly.

> >  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.
> 
> Do you think Max would run more reliably and efficiently than pd?  I
> never tried Max on an embedded device (it would be impossible, as you
> point out, unless that device was already running windows or MaxOSX)
> but in my experience Max is not, be default, more efficient or
> reliable than Pd.  It really is context (and code) dependent.

No, Max would be terrible for my requirements.  But it's nice to use from what I've seen ...

My point is, I wish pd didn't force me to work it's way but allow me to
work my way.  That's the beauty of patching as opposed to vsts, etc.
You have to build form the ground up.

> Yes, pd could benefit from a face-lift and optimization and whatnot to
> make it more user-friendly and more pleasant to work with (and more
> efficient!).  So far, most proposed changes were somehow ignored or
> set aside and various branches of pd or pd-like projects never lifted
> off the ground.

What is the state of all these changes?  As I said before, I'm willing
to help but not if said changes and progress won't go anywhere, then
count me out.  I'd rather just learn some dsp and do it myself because
at least I would be able to make changes depending on my needs.  Of
course, then I'd waste even more time programming and not playing ...
*sigh*

pd is great, but it's like getting kicked in the balls and face
sometimes.
  

  I LIKE LINUX AND     .'  `.  
 GETTING KICKED IN --- |a_a  | 
THE BALLS AND FACE     \<_)__/ 
                       /(   )\ 
                      |\`> < /\
                      \_|=='|_/

---
Dan Wilcox
danomatika.com
robotcowboy.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090526/91568e9f/attachment.htm>


More information about the Pd-list mailing list