<div><div>&quot;As I never studied the fft part really closely, it still remains a mistery to me (although the function of each segment is described). Can someone point me to a place where to make sense of what&#39;s happening around? Or I should just go through all the tutorials until I get here?&quot;</div>
<div><br></div><div>Hi, before I go to your questions, let me mention about this, and I open this up to other people who may be interested.</div><div><br></div><div>At the Pd Convention I did this workshop that covered that. I have rewritten the patch in a way that seems easier to make sense of what&#39;s happening, dividing it in subpatches and everything. I firs did this in portuguese, so you&#39;re in luck, as you can read it, so I will send it to you. But I got a lot from <a href="http://cycling74.com/2006/11/02/the-phase-vocoder-–-part-i/">http://cycling74.com/2006/11/02/the-phase-vocoder-–-part-i/</a></div>
<div><br></div><div>About 2 years ago I released my phase vocoder abstractions. Inside the workings of the patch you will see it rewritten in this new way. You can still check them at <a href="http://sites.google.com/site/porres/PhaseVoc.zip">http://sites.google.com/site/porres/PhaseVoc.zip</a></div>
<div><br></div><div>I will send you the portuguese text I wrote on the Phase Vocoder that explains it all.</div><div><br></div><div>These patches are kinda old now, and I&#39;ve been working on new stuff. As I said, now you can use any sample rate, but more than that, they stopped being just &quot;phase-vocoders&quot; and they do a whole lot of other stuff, including stuff from my PhD. I&#39;m gonna release them soon a in a couple of months, when I finish my PhD. After that, I may break this super patch into new pieces, so they can be just phase vocoders again.</div>
</div><div><br></div><div>Now, the questions.</div><div><br></div><div>&gt; The no-detune bang should send 0 to transpo-set instead, right?</div><div>&gt; <span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">[pd hann-window]: the variables window-msec and window-sec don&#39;t have receive counterparts. </span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">&gt; Probably a remain from an old patch?</span></div><div><br></div><div>Yep. Bugs.</div><div><br></div>
<div><div><div>&gt; <span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Location display (main window, leftest) is in msec of the original sample, right?</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Yeah, it displays the sample time-line in msec.</span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></span></div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">&gt; </span><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">[s location-set] in [pd read-windows]: since this variable gets its value from [r see-loc] (which is banged~), </span></div>
<div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">&gt; it doesn&#39;t need to receive the value from [r location], right?</span></div><div><br></div><div>
It does not, but if you send a value from the location display number box, you can &quot;freeze&quot; the sound file on that spot.</div></div><div><br></div><div>That&#39;s what I do to freeze/unfreeze the files in my abstractions</div>
</div><div><br></div><div>&quot;in [pd read-windows], there&#39;s the [r $0-insamprate], is supposed to make &quot;sample rate correction&quot;. Tracking from where this value comes, it leads to the sample loading subpatch, [pd insample] in the main window. There, the connection doesn&#39;t make sense to me:<br>
 a) the right outlet of [unpack s f] never should give out something, as [openpanel] only delivers a symbol.<br> b) so, the patch is hard coded to bang a 44100 to [s $0-insamprate]&quot;<br></div><div><br></div><div>Hi, I see, what it does is that if you send a message with an extra atom account for the file&#39;s sample rate, it will unpack and overwrite the 44100 sample rate. But in the event of you not doing that, it will be 44100 as a default value. That&#39;s it. So you basically need to specify the sample rate of your loaded sound file if it is different than 44100.</div>
<div><br></div><div>The value goes to $0-insamprate and is </div><div><br></div><div>&gt; if both loaded sample and patch have the same sample rate, this variable isn&#39;t really necessary, as it will give out 1, right? </div>
<div>&gt; (which will be multiplied with the transposition, therefore changing nothing).</div><div><br></div><div>Yes, but if you specify a different rate according to the loaded sample, which is different than the sample rate of the patch, or different to 44100, it will apply a different transposition window, that&#39;ll keep the pitch of the sound file as intended.</div>
<div><br></div><div>And when Pd&#39;s sample rate is different than 44.1khz, this makes the loaded samples (which are mainly at 44.1khz) be transposed accordingly.</div><div><br></div><div>Anyway, I re adapted my new patches to work with any sample rate now! But the ones released and that I&#39;ve resent here are still hardcoded to 44.1khz</div>
<div><br></div><div>&quot;When pressing rewind, the location value goes to a small negative number. I gather that that&#39;s the half of msec for the window lenght. Why does a sample playback start there, instead of directly in 0? So that the front window starts on time, while the back window is delayed? (as explained in [pd read-windows])&quot;</div>
<div><br></div><div>I figure it is because this is the mid-point between two consecutive windows. And the phase vocoder needs to analyze two consecutive windows. So we always have this latency issue with the phase-vocoder. And I guess we need to start there so it will get first the second window right, and on the next step do the phase accumulation.</div>
<div><br></div><div>Anyway, I understand it won&#39;t make much of a difference if you&#39;re dealing with that latency in respect to a loaded sound sample. And you can even do smething to chabge that, I suppose. No problem. But if you&#39;re recording samples on the fly, and applying the phase vocoder in it, you cant avoid the latency. I mean, I&#39;ve adapted the phase vocoder patch to do exactly that, which is start transposing and changing tempo as soon as start recording. So this particular issue was something I had to deal with.</div>
<div><br></div><div>Maybe Miller or others have stuff to say, but that&#39;s what I got.</div><div><br></div><div>Cheers</div><div>Alex</div><div><br></div><div><br></div><br><br><div class="gmail_quote">2011/9/18 Joćo Pais <span dir="ltr">&lt;<a href="mailto:jmmmpais@googlemail.com">jmmmpais@googlemail.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
This is a long mail. I was having a closer look at the I07 vocoder example, and wanted to ask a couple questions (some of them general, some a bit petty). They&#39;re divided into parts, in case someone doesn&#39;t want to answer everything:<br>

<br>
- in [pd read-windows], there&#39;s the [r $0-insamprate], is supposed to make &quot;sample rate correction&quot;. Tracking from where this value comes, it leads to the sample loading subpatch, [pd insample] in the main window. There, the connection doesn&#39;t make sense to me:<br>

 a) the right outlet of [unpack s f] never should give out something, as [openpanel] only delivers a symbol.<br>
 b) so, the patch is hard coded to bang a 44100 to [s $0-insamprate]<br>
<br>
Since the whole patch can work with any sample rate, what is the function of the 44100? Does it assume that the loaded samples will be at 44.1KHz? So, a [wavinfo~] or similar object that says the samplerate of the loaded file would be better, right?<br>

And, if both loaded sample and patch have the same sample rate, this variable isn&#39;t really necessary, as it will give out 1, right? (which will be multiplied with the transposition, therefore changing nothing).<br>
<br>
So, resuming: does this connection recalculates the playback rate of the $0-sample table, assuming that the loaded sample is always at 44.1KHz, and the patch&#39;s sample rate can be variable?<br>
<br>
- - - - - -<br>
<br>
When pressing rewind, the location value goes to a small negative number. I gather that that&#39;s the half of msec for the window lenght. Why does a sample playback start there, instead of directly in 0? So that the front window starts on time, while the back window is delayed? (as explained in [pd read-windows])<br>

<br>
- - - - - -<br>
<br>
Location display (main window, leftest) is in msec of the original sample, right?<br>
<br>
- - - - - -<br>
<br>
[s location-set] in [pd read-windows]: since this variable gets its value from [r see-loc] (which is banged~), it doesn&#39;t need to receive the value from [r location], right?<br>
<br>
- - - - - -<br>
<br>
[pd hann-window]: the variables window-msec and window-sec don&#39;t have receive counterparts. Probably a remain from an old patch?<br>
<br>
- - - - - -<br>
<br>
The no-detune bang should send 0 to transpo-set instead, right?<br>
<br>
- - - - - -<br>
<br>
As I never studied the fft part really closely, it still remains a mistery to me (although the function of each segment is described). Can someone point me to a place where to make sense of what&#39;s happening around? Or I should just go through all the tutorials until I get here?<br>

<br>
<br>
In case it interests to anyone, I&#39;ve made a local version of the patch, with all variables and tables preceded with $0.<br>
<br>
<br>
Thanks again,<br><font color="#888888">
<br>
Joćo Pais<br>
</font></blockquote></div><br>