That fl.tomax~ crash
Issue #26
resolved
Having trouble making an isolated example, but this patch now crashes quite consistently within a few seconds of turning on dsp :-D
(I appreciate that it's almost certainly doing something silly)
(if the fl.convolve~ gets reconnected, then you get a different crash immediately, but that feels like it should be more isolatable)
Comments (5)
-
repo owner
-
repo owner
Actually 32,767 is a hard limit on max list length. After that you prob need a matrix or something like that.
-
repo owner
I can't repo your fl.convolve~ crash - any chance you could give me a straight repro patch for that?
-
reporter
Just clip it, I would have thought (if there's a hard limit IAC). In this particular case, I'm just using the tomax~ as a glorified bang and was too lazy to shorten the output in framelib (presumably causing lots of totally needless memory allocation).
I'll see if I can isoloate the convolution one - I suspect a 0-length frame might have been involed.
-
repo owner
- changed status to resolved
OK - I'm going to assume that the crash you were seeing is the one that occurred when the two inputs both had a size of one (when the convolution simplifies to a single multiplication) - the apple FFT code was barfing on this, so I've made a special branch for it for the next one.
- Log in to comment
Yeah - OK - so it looks like as the call to schedule_delay takes a short (signed) that if you try to send over 32768 values you overflow into a negative number (in a 16bit int). What would you like me to do here?