[PD] speedlimit of data in Pd

IOhannes zmölnig zmoelnig at iem.at
Thu Jun 28 21:37:25 CEST 2012


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120628/ce11a835/attachment.pgp>


More information about the Pd-list mailing list