On 2013-11-26 19:37, Alexandre Torres Porres wrote:
[1] https://sourceforge.net/p/pure-data/feature-requests/16/
Not sure if I got what the request was requesting.
"the parameter s->s_sr isn't defined properly, as s->s_sr=(fs*overlap) has nothing to do with the actual sampling interval applied to the audio data."
the question is how you define samplerate. a simplisitic approach simply takes the number of samples processed within e.g. 1 second. if you do overlap by 2, you process each incoming sample twice, so the number of samples that passes through the object is doubled, and thus the sample rate is doubled as well.
this however doesn't really make sense, if you use that samplerate to calculate the period of a periodic signal, like [osc~] does.
e.g. an [osc~ 689.062] will have a period length of 64 samples (@44.1kHz).
when we do upsampling, the internal samplerate is 88.2kHz, thus the period length is 128 samples. when going back to the original samplesize, you need to do downsampling, which basically means to only take every second sample (in the most simple form), so you end up with half of the samples discarded and the period size of 64 again.
however, with overlapping things are not as simple. the internal samplerate is again 88.2kHz, the period length 128 samples. but this gives us two problems:
canvas and in the reblocked (overlapped) sub-canvas). but [osc~] will create a "continuous" signal between two calls, as it doesn't know anything about overlapping. this is plain wrong for overlapping signals, where the odd frames should be considered continous, and the even frames are continuous, but not both together.
reduce the number of samples by a factor-of-two. but this time the algorithm used is to align the half-blocks and "sum" the up. but this means, that you still have a period size of 128 samples. which will make ~344Hz in the parent patch...(and the odd artifacts you get from the problem #1)
hope this clears things a bit.
the statement in the feature-request/bugtracker kind of addresses this: in Pd the signal-block's "sample rate" is not the inverse of the "actual sampling interval" (think nyquist and the like) but "the number of samples processed in a given time" - which simply isn't the same if you do overlapping....
fmdsar IOhannes