[PD] speedlimit of data in Pd

João Pais jmmmpais at googlemail.com
Thu Jun 28 20:49:20 CEST 2012


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.

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? 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.

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



More information about the Pd-list mailing list