[PD] speedlimit of data in Pd

[João Pais]

thanks, that and other's [until] suggestion answers most of the questions.

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