Hello!
I'm running into some issues with a relatively intensive granular patch I've been working on, and I'm wondering whether increasing my block size would be a good thing to try.

However I am unable to successfully change the block size from 64, either by using block~ or in the audio settings dialog. If I do it via block~ the size is unchanged. If I attempt to change the block size in my audio settings the window freezes - I'm unable to close it, PD becomes unresponsive, and I have to force quit and restart the application (at which point the block size is back to 64).

I have two Macs, and the behaviour is the same on both. One is a slightly older MacBook Pro running OS 10.13.3 and PD 0.48.0. The other is a new MacBook Pro running OS 10.13.4 and PD 0.48.0 (386). The behaviour is also the same both when I'm using my built-in audio card and when I'm using my RME Fireface UCX (over USB).

I have two interrelated questions - is changing the block size advisable as a method for trying to improve performance? I've always assumed it's similar to the "vector size" in Max/MSP, is that right? I'm not entirely certain that the problems I'm having will be fixed by changing the block size, but I'd like to try.

Secondly - is my inability to change the block size a known bug, or something I am doing wrong?

I'll be posting this on a few other PD forums, apologies if you read them all. Thanks!

I should also say that I've found another forum post that seems to be similar from about two years ago: https://forum.pdpatchrepo.info/topic/10180/mac-cannot-change-blocksize/2

The solution there was to install and use Jack - I've done this to no effect (and I'd rather not do that anyway).

I wanted to chime in a say I am experiencing this problem as well. To recreate:

1. Launch pd
2. Open audio settings
3. Change block size from 64 to 256 or higher
4. Audio settings window doesn't close. All other windows stop responding.

I'm running:
MBP, MacOS 10.13.4, pd 0.48-0

Any help with this would be fantastic!

@amazingrolo The audio settings dialog changes how Pd talks to the soundcard driver. If the souncard doesn't like the settings that will hang Pd (Pd will be waiting for the soundcard to say "ok thanks" and the soundcard will be saying "eh..!"..).
If you want to change the block size you will have to do it for the soundcard as well. "64" is standard.

Pd schedules audio processing ticks in 64 sample chunks anyway, so I am not sure there is an advantage to using [block~] in a heavy patch. In fact I would think that changing block sizes would have a cost.
If your patch is not "live"..... you have no connection from adc to dac..... increasing the Delay (mSec) wil help more. It will increase the latency by using a bigger buffer.

A few mistakes are possible using [block~] or [switch~]..... with [throw~] for example......
http://puredata.info/docs/manuals/pd/x2.htm chapter 2.4.4 onwards.

I have had trouble while changing [block~] parameters ..... but once it is set in the patch (patch saved and re-opened or audio toggled on/off) it is fine. That is painful when you are experimenting though.
David.

@amazingrolo One thing worth trying is to use a [switch~] object inside each grain abstraction to turn off the dsp for that abstraction when the grains are not active. So you'd send a 1 to [switch~] just before the grain starts, and then schedule a zero after a delay time as long as the grain length in milliseconds.