[PD] speedlimit of data in Pd

[Jonathan Wilkes]

----- Original Message -----
> From: João Pais <jmmmpais at googlemail.com>
> To: PD-List <pd-list at iem.at>
> Cc: Miller Puckette <msp at ucsd.edu>
> Sent: Thursday, June 28, 2012 2:49 PM
> Subject: [PD] speedlimit of data in Pd
> 
> Hello,
> 
> I'm comparing the x mouse position to the position of scalars displayed in
> the screen - so that I have a sample player that plays the samples
> where/when my mouse is sitting over.
> Since [pointer] only allows for a [next( method - no "previous" or an
> extra X command to jump several pointers -, the easiest implementation to
> search for a match is to start from the beginning of the list, and going
> [next( until a match happens. This works out fine usually, until the limit
> of 160 pointers. After that, I get always the stack overflow error in the
> object doing the loop - in this case, a [t b p], but I guess it doesn't
> matter much.

Are you using a recursive loop (i.e., making a connection from an outlet of
an object at the bottom of an object chain to the inlet of one above it)?

If so, replace that method of cycling through the scalars with an iterative
loop (i.e., an [until] loop).

> 
> This is a kind of general problem: What is the "speedlimit of data" in 
> Pd?
> How many operations can be done until a stack overflow occurs?

There is a place where the limit is hardcoded-- that's what gives the "buffer
overflow" error.  It protects against infinite recursive loops in some cases but
not in others, as well as being a nuisance when you need to have a recursive
loop more than 1,000 levels deep.  I think matju precisely explained how it
works on the list somewhere (definitely more precisely than I can).

> That also
> happens when I try to automatically load the contents of a not-so-big
> [textfile] into an array with a click - unless I add a [del 1] to the
> loop. If the operation isn't in realtime, the problem can be circumvented,
> but anyway the issue is there.

I'm not familiar with that operation, but again check that you're using an
an iterative [until] loop and not a recursive loop.

Save recursive looping for the times when want to show off how
insanely complicated doing recursive loops is in Pd.  (I can't even say
only do it when you're only going less than 1000 levels deep because it
depends on the size of the object chain over which the recursion is
happening.)

> 
> How is it possible to increase the "control rate" in Pd? I tried 
> changing
> the sample rate from 44.1 to 48, but there was no (small) change. I
> thought that it was a factor of the audio rate. Is there a non-empirical
> way of knowing the limits of Pd, or of the system it's operating in? Is
> the latter that important in this equation?
> 
> 
> To solve my problem at hand, I could try an approach that tries to
> eliminate some of the comparison operations in the patch. But in the end
> there is still the loop between [next( and [pointer], and I imagine that
> it wouldn't make a big difference.
> 
> 
> System: Thinkpad x61, w7, pd-ext-0.43
> 
> Best,
> 
> João
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>