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.
Cheers Thanks
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/
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 what's really confusing, cause I can't seem to get it.
If you do upsampling with block, for instance, you don't get this frequency change issue with [osc~]. It'll run the same frequency, no problem... but overlapping will do that somehow.
Why the hell the actual upsampling does not affect it?
And does this mean that overlap of 4 and upsampling of 4x makes it really run at 16x the sample rate?
cheers
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
[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
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
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 correctly
On the other hand, I'm getting really nice and distorted wicked sounds from this error, and I'm gonna use it! haha
All the best
2013/11/26 IOhannes m zmölnig zmoelnig@iem.at
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
-
Alexandre Torres Porres -
IOhannes m zmölnig