On 17/01/2015 13:54, IOhannes m zmölnig wrote:
On 01/17/2015 01:25 PM, Alessio Degani wrote:
On 16/01/2015 19:33, IOhannes m zmölnig wrote:
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)
Humm... I didn't know that there are different way to handle audio stream in PD. Can PD directly manage overlapp and stuff like that? Where I can read something about that?
putting a [block~ 128 2] anywhere in your canvas will make it use signal vectors of 128 samples length with an overlap factor of 2 (read: the last 64 samples of the old signal vector are the same as the first 64 samples of the new one).
the objects themselves are not notified of this, they just get 128 sample chunks to process. inspecting the signal-vector's samplerate (sic!, it's really a data-rate) will reveal that it has now the double samplerate as when using [block~ 128].
Just to be sure: using [block~ 128 2] means that the dsp routine of the external is called each 64 samples, and a vector of 128 samples is passed to the dsp routine? And plus, the first half of the vector si the same as the second half of the previous buffer?
Now... another question is coming up. Your output is 64 or 128 samples? If 128, Pd will use the overlap-add policy (second half of the previous ouput buffer + first half of the actual)? If so, the programmer of the external needs to know how to deal with that! For example, if I have no need of overlap-add, I've to set second half of my output buffer to zero! It's not a good practice :) so I think that I've missed something hehehe :)
Thank you
fgmsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list