It never even occurred to me to even test other buffer sizes than 64, 128, 512, 1024.
Never assume that hardware buffer sizes are a power-of-2! There are even some built-in sound cards that *only* run on a single fixed weird buffer size.
Conversely, never assume that all audio processing algorithms run at power-of-2 block sizes. For example, the Opus encoder/decoder requires block sizes like 120, 240, 480, 960, etc. (multiples of 2.5 ms @ 48 kHz).
Finally, be aware that VST plugins don't use a fixed block size! The block size passed to the setup function (VST3: "maxSamplesPerBlock" in "Vst::ProcessSetup") is only the *maximum* number of samples you will ever attempt to process. The actual number of samples passed to the process function (VST3: "numSamples" in "Vst::ProcessData") can vary between processing calls! This is necessary so that DAWs can process "incomplete" blocks, e.g. for playback start, for accurate looping or before tempo changes (so that the tempo change happens exactly at the start of a block).
If a processor depends on a fixed processing block size - as is the case with Pd - you generally have to buffer the inputs/outputs. This obviously adds latency, but most DAWs have latency compensation.
Note that you also have to buffer MIDI messages (and use appropriate time stamps)!
For example, this is what Camomile does: https://github.com/pierreguillot/Camomile/blob/dev/v1.0.8/Source/PluginProce...
One general problem to be aware of: Once a processing block is smaller than or not a multiple of DEFDACBLKSIZE, all following blocks will effectively be offset by that amount of samples. For MIDI messages this is not a real issue because they are timestamped. However, any kind of transport information, like the project play head or tempo changes, is only provided once per block. If the plugin relies on this information, the output might not be perfectly aligned with the rest of the project.
Of course, it would be nice if this was already handled in libpd itself (as an option). Buffering the audio input/output would be the easy part. libpd would also have to automatically delay incoming MIDI messages and buffer + delay outgoing MIDI messages. I think it's doable, but it's not trivial.
Christof