> hope this clears things a bit.
I can't see how it could be any clear :D
thanks so much for the detailed explanation, really appreciate it
I finally know how overlapping is actually done behind the scenes now, cool
And yeah, objects like [osc~] should totally be aware of this matter and do
it
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
> int
> [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 overla
thanks master
well, I was betting it was that, and it actually brings me to more direct
questions I should have asked before. So here they go.
Simply put: How come and why does overlapping affect the sample rate?
> the same happens if you raise the "samplerate" via "upsampling".
I guess this is
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 wha
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
