Hi there, how&#39;s everything?<div><br></div><div>I sent this other remark to the pd-list the other day, no replies, maybe I should insist with you. It&#39;s about the time parameter for [line~], which doesn&#39;t need to be that, and just seems to have to not be too slow, windows and overlap will reconstruct it, and even if that parameter is ridiculously fast, it doesn&#39;t matter.</div>

<div><br></div><div>Now I also found other issues on the implementation in I07; you perform a normalization at a first stage on the previous FFT output. I thought about it and assumed it&#39;s not necessary. So I took it out, and it still sounds equally fine.</div>

<div><br></div><div>And on the normalizaion section, &quot;salting&quot; the signal with a small amount (such as 1e-15) in the case of zeroes, prevents division by zero, and gives a magnitude of 1, but will give you a phase shift that is not &quot;zero&quot;. So I thought of another way with [expr~] that outputs magnitude of 1 and 0 phase. </div>

<div><br></div><div>Anyway, I&#39;m updating that into my computer music examples with Pd, and any remark you should have is welcome.</div><div><br></div><div>Thanks</div><div><br></div><div>Hope you have a well deserved holiday&#39;s season of rest and peace.</div>
<div><br></div><div>alex</div><div><br></div><div><br><br><div class="gmail_quote">2011/12/11 Alexandre Torres Porres <span dir="ltr">&lt;<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>&gt;</span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi there. I&#39;ve been opening the guts of the phase vocoder patches for a while now, and rewriting them, having it in new forms, etc...<div>

<br></div><div>And... today I had this doubr. You see, lets have the regular I07 example. Now, we feed [line~] objects with where to start and where to go in a time specified as the FFT analysis Hop size in ms. </div>
<div><br></div><div>I was wondering if that wasn&#39;t just too fast. And why wasn&#39;t the time for [line~] the actual window size in ms. That is because I assumed this [line~] controlled somehow the speed playback we hear.</div>


<div><br></div><div>So I put a number box and started messing around with it, making it a bigger time lenght and hoped to listen to some sound change (maybe speed), just for fun. To my surprise, nothing happened!!! That is until I reached two overlaps (1024 points instead of 512). </div>


<div><br></div><div>So instead of making anything clearer than it was, it got pretty much more weird. I decreased the values until reaching a supidly small time inteval of micro ms, something like 2.26e-07, and it still worked!!!</div>


<div><br></div><div>I now have the clear idea that this length in ms is not that important at all. But that it has to be fast just to make line output the audio so it gets in the FFT. If it takes to long (2 overlaps or longer) it ruins everything. But what really controls the thing is the time interval defined by the counter which is controlled by the speed parameter. </div>


<div><br></div><div>[line~] needs to feed the [tabread4~] output at a rather free way.</div><div><br></div><div>Anyway, some nerdy remark. I&#39;d like to understand this better, and explain this better in my rewriting of the patches.</div>


<div><br></div><div>Thanks</div><div>Alex</div>
</blockquote></div><br></div>