I'm trying to half-fill a table. I'm using tabwrite~ within a patch that has block~ set to half the table-length. The results are good with a block size above 64, but below that, it fully fills the table. I know pd's default block size is 64. Is this related? Or is there something I'm missing?

I notice if i down-sample the block, I can get the results I want. downsampling to .5 gets desired results at 64, and .25 gets me 32. I feel like there's something basic about dsp that I'm not getting. I don't understand why I need to downsample?

I've attached a simple example patch, but it doesn't do the downsampling (just add .5 or .25 at end of [$1 1] message in pd zero_pad

paddedTest.pd

Has anybody used kiosk-plugin (via deken) on a raspberry pi?
I downloaded and tested on osx and it works great, but when I try on the raspberry pi, the options I tried (disabling menus and making full-screen), didn't work. The console seems to think the plugin is loading properly. Is there a known issue?

pd version 0.51.4,
rpi os bullseye

Reading a bit, it seems that 50 is the default. I have no idea how mine ended up so low. My laptop isn't so old, and I was a bit surprised that everybody was getting better results than me haha. Anyway, I'm going for responsive, so I'll keep it as low as I can without getting those dropouts. Thanks again

Thanks for all the thoughts!
@whale-av @jameslo you were right about the audio delay. Increasing from 5 of 8 ms did the trick!

Thanks for replying. It's part of a pretty large project and woud be hard to isolate, but I've reproduced the dropouts with something simpler:

fftDropoutExample.pd

It is literally the phase vocoder tutorial patch with a whole bunch of extra fft-analysis windows running simultaneously. my cpu is at 16% but there are loud clicks at random intervals.

I'm not sure that the fft has anything to do with it, except that I haven't otherwise had dropouts without high cpu usage.

Hi, I have a patch that is using rfft, similar to the phase-vocoder tutorial patch. It is operating accurately and reliably until I use a large window size while have a number of instances running at once. Then I start getting crackling sounds that sound to me like audio dropouts.
When I use the cputime object, it looks like I'm well below the threshold for where I would expect problems (hovering around 20%). Activity Monitor/Task Manager shows about 20% as well, and the total cpu load is low.

I am not surprised that there are artifacts when I have too many instances of the patch running at once, but I'm surprised that it doesn't show up as cpu overrun. Are there other diagnostic tools I can use that would help me predict when I will start to hear arifacts?
thanks