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