[PD] Correct way to precess an audio stream

[IOhannes m zmölnig]

On 01/16/2015 12:23 PM, Alessio Degani wrote:
> Hi list,

[...]

> When you want to write a PD external that process audio stream, the
> scenario is:
> 1- PD passes chunked audio stream to the inlet of the external and read
> an audio chunk from the outlet of that external.
> Each input and output chunk is of fixed length of, say, Nc samples. Each
> chunk is a NON-overlapped adjacent chunk of the audiostream to be
> processed.

i hope you are aware that this is a simplification on your side, and not
how Pd handles audio streams (when it comes to overlapping)

> 
> My question is:
> There is a standard way, a "design pattern", to manage this kind of
> processing?

i don't know of a standard "design pattern" but there are two ways that
come to my mind:

- implement a ring-buffer where you put the sample chunks delivered by
Pd, and read/use them whenever you have collected enough data.
overlapping is very simple to implement (as long as you don't overwrite
the data :-))

- let Pd do the partitioning and overlapping.
this should be the preferred way, but obviously only works if you can
live with Pd's constraints regarding overlap (overlap-factor mus be a
power-of-two).
you should make your algorithm accept any block-size that Pd accepts
(any power-of-two); if this does not work for whatever reasons, you
could simply check whether the user has set the correct
blocksize/overlap when DSP is turned on, and refuse to work if the
settings do not match your expectations (and print an error() so the
user knows why it's not working).
(the main drawback with this approach is, that there is currently no
entirely sane way to uniquely identify the overlap factor. as long as
now re-sampling is used, it's fairly easy though)



gfmdar
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150116/5a0e96b3/attachment.sig>