<div dir="ltr">thanks master<div><br></div><div>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.</div><div><br></div><div>Simply put: How come and why does overlapping affect the sample rate?</div>
<div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:12.800000190734863px">the same happens if you raise the "samplerate" via "upsampling".</span></div><div><br></div><div>I guess this is what's really confusing, cause I can't seem to get it.</div>
<div><br></div><div>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.</div><div>
<br></div><div>Why the hell the actual upsampling does not affect it?</div><div><br></div><div>And does this mean that overlap of 4 and upsampling of 4x makes it really run at 16x the sample rate? </div><div><br></div><div>
cheers</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/26 IOhannes m zmölnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 2013-11-26 11:19, Alexandre Torres Porres wrote:<br>
> Howdy, ever tried to compute a hann window inside a subpatch where the FFT<br>
> is happening?<br>
><br>
> And then if you're overlapping it by 4, do you see that only 1/4 of the<br>
> cycle from [osc~] came up?<br>
><br>
> That means the [osc~] frequency was 1/4 what it should be...<br>
><br>
> Now, why and how does it happen? I just have no clue at all.<br>
><br>
<br>
</div></div>that is mainly because the "sample rate" within the overlapped canvas is<br>
higher than the sample rate outside.<br>
(e.g. if you are doing an overlap of 2, you are in fact processing the<br>
double amount of data in the same time, so your overlapping "sample<br>
rate" is 88200 if the non-overlapping rate is 44100).<br>
the same happens if you raise the "samplerate" via "upsampling".<br>
<br>
<br>
[osc~] uses the sample-rate information (within the signal data<br>
structure) to calculate the phase of a cosine-table lookup.<br>
<br>
btw, there has been a long-standing feature request [1] to extend the<br>
signal-structure to hold both overlap factor and sample-rate, so<br>
signal-processing objects could handle upsampling and overlapping<br>
differently.<br>
(speaking of which, it would also be nice, if any dsp object could have<br>
a notion of the current overlap cycle)<br>
<br>
<br>
gfmasr<br>
IOhannes<br>
<br>
<br>
[1] <a href="https://sourceforge.net/p/pure-data/feature-requests/16/" target="_blank">https://sourceforge.net/p/pure-data/feature-requests/16/</a><br>
<br>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>