[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."
Is this bit just saying overlap in [block~] is done wrong and shouldn't affect sample rate?
Cause I'd be right there with it...
2013/11/26 IOhannes m zmölnig zmoelnig@iem.at
On 2013-11-26 11:19, Alexandre Torres Porres wrote:
Howdy, ever tried to compute a hann window inside a subpatch where the
FFT
is happening?
And then if you're overlapping it by 4, do you see that only 1/4 of the cycle from [osc~] came up?
That means the [osc~] frequency was 1/4 what it should be...
Now, why and how does it happen? I just have no clue at all.
that is mainly because the "sample rate" within the overlapped canvas is higher than the sample rate outside. (e.g. if you are doing an overlap of 2, you are in fact processing the double amount of data in the same time, so your overlapping "sample rate" is 88200 if the non-overlapping rate is 44100). the same happens if you raise the "samplerate" via "upsampling".
[osc~] uses the sample-rate information (within the signal data structure) to calculate the phase of a cosine-table lookup.
btw, there has been a long-standing feature request [1] to extend the signal-structure to hold both overlap factor and sample-rate, so signal-processing objects could handle upsampling and overlapping differently. (speaking of which, it would also be nice, if any dsp object could have a notion of the current overlap cycle)
gfmasr IOhannes
[1] https://sourceforge.net/p/pure-data/feature-requests/16/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list