----- Original Message -----

From: João Pais jmmmpais@googlemail.com To: PD-List pd-list@iem.at Cc: Miller Puckette msp@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 06/28/2012 08:49 PM, João Pais wrote:

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.

you get a stack overflow if you have "about" 400 (iirc) objects in a "row". whenever an objects sends something to its outlets, the stack is saved and not restored until "everything below" it has executed.

there has been some talk about making the maximum stack depth settable as a cmdline arg, but i guess nobody every implemented that. (usually you want a maximum stack depth, as it allows you to survive a recursive patch without exit condition)

This is a kind of general problem: What is the "speedlimit of data" in Pd?

what do you mean by "speedlimit".

How many operations can be done until a stack overflow occurs? That also

i don't get how "speedlimit" and "stack overflow" go together in this context.

the problem is more: since Pd-messages are executed as fast as possible, you need to use the stack. or put the other way round: if you can live with breaking linearity (by splitting a message chain using [delay 0]), then the stack will not overflow.

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.

depends on how you do the loading. avoid recursion, use iteration. (read: use [until] rather than feedback)

How is it possible to increase the "control rate" in Pd? I tried changing

buy a faster CPU.

the control rate in Pd is only limited by the CPU. if (and only if) you have enough idle time to do some DSP-processing inbetween message processing, then your messages will be done in bursts every 64 samples.

mfsdagfa IOhannes