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.
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
Best,
João