[PD] why overlaps affect frequency of [osc~]?
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why overlaps affect frequency of [osc~]?
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/ signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why overlaps affect frequency of [osc~]?
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 zmoel...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why overlaps affect frequency of [osc~]?
[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 zmoel...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why overlaps affect frequency of [osc~]?
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 signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] why overlaps affect frequency of [osc~]?
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 zmoel...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
