[PD] why overlaps affect frequency of [osc~]?

[Alexandre Torres Porres]

> 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 at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20131126/a28ce97e/attachment-0001.htm>