[PD] Arbitrary buffer sizes in pd, libpd

[Christof Ressi]

> 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/PluginProcessor.cpp#L297

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