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:
- imagine that the blocksize was still 64 samples (both in the parent
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.
- when going back to the non-overlapping parent canvas, we again have to
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


_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list