[PD] CPU saving strategies

David Schaffer schafferdavid at hotmail.com
Mon Aug 2 13:16:24 CEST 2010


Thanks for your advices Franck, these are the kind of programming tips I was looking for.
 
David
 
 

http://www.flickr.com/photos/schafferdavid/

http://audioblog.arteradio.com/David_Schaffer/


 

> Date: Mon, 2 Aug 2010 13:02:00 +0200
> From: fbar at footils.org
> To: pd-list at iem.at
> Subject: Re: [PD] CPU saving strategies
> 
> Hi,
> 
> On Sun, Aug 01, 2010 at 12:35:41PM +0200, David Schaffer wrote:
> > I recently built a midi CC sequencer abs. It helps me add some
> > timeline-based control to my patches. But I came across a problem I never
> > had to deal with before: CPU consumption. I realized I could'nt use more
> > than four instances of my sequencer before the patch would become
> > unmanageable (interface freezes, audio drops, and, finally... a crash) I
> > think this is related to the use of large size arrays. I would be grateful
> > if someone out there could point me to a better data storing/ CPU saving
> > strategy for my sequencer, maybe data structures? Thanks in advance.
> 
> You're using way too many debugging GUIs, like [bng] or number boxes. Remove
> all of them that you don't see and optionally speedlimit the updates of those,
> that you want to see. [m_speedlimit] from rj (http://github.com/rjdj/rjlib) can
> be used for speedlimiting.
> 
> In general, never patch debuigging stuff like this: 
> 
> [...]
> |
> [0\ <- a numberbox
> |
> [...]
> 
> or this: 
> 
> [...]
> |
> [bng] <- a GUI bang
> |
> [...]
> 
> 
> Instead always put the debugging GUIs into their own path like here: 
> 
> [...]
> |\
> | [0\ <- a numberbox
> |
> [...]
> 
> This way it's easier to remove them later, when you're finished debugging your
> patch. Make that a habit.
> 
> Ciao
> -- 
> Frank Barknecht Do You RjDj.me? _ ______footils.org__
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100802/d3ffc463/attachment.htm>


More information about the Pd-list mailing list