"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's happening around? Or I should just go through all the tutorials until I get here?"
Hi, before I go to your questions, let me mention about this, and I open this up to other people who may be interested.
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's happening, dividing it in subpatches and everything. I firs did this in portuguese, so you're in luck, as you can read it, so I will send it to you. But I got a lot from
http://cycling74.com/2006/11/02/the-phase-vocoder--part-i/
I will send you the portuguese text I wrote on the Phase Vocoder that explains it all.
These patches are kinda old now, and I've been working on new stuff. As I said, now you can use any sample rate, but more than that, they stopped being just "phase-vocoders" and they do a whole lot of other stuff, including stuff from my PhD. I'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.
Now, the questions.
> The no-detune bang should send 0 to transpo-set instead, right?
> [pd hann-window]: the variables window-msec and window-sec don't have receive counterparts.
> Probably a remain from an old patch?
Yep. Bugs.
> Location display (main window, leftest) is in msec of the original sample, right?
Yeah, it displays the sample time-line in msec.
> [s location-set] in [pd read-windows]: since this variable gets its value from [r see-loc] (which is banged~),
> it doesn't need to receive the value from [r location], right?
It does not, but if you send a value from the location display number box, you can "freeze" the sound file on that spot.
That's what I do to freeze/unfreeze the files in my abstractions
"in [pd read-windows], there's the [r $0-insamprate], is supposed to make "sample rate correction". Tracking from where this value comes, it leads to the sample loading subpatch, [pd insample] in the main window. There, the connection doesn't make sense to me:
a) the right outlet of [unpack s f] never should give out something, as [openpanel] only delivers a symbol.
b) so, the patch is hard coded to bang a 44100 to [s $0-insamprate]"
Hi, I see, what it does is that if you send a message with an extra atom account for the file'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's it. So you basically need to specify the sample rate of your loaded sound file if it is different than 44100.
The value goes to $0-insamprate and is
> if both loaded sample and patch have the same sample rate, this variable isn't really necessary, as it will give out 1, right?
> (which will be multiplied with the transposition, therefore changing nothing).
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'll keep the pitch of the sound file as intended.
And when Pd's sample rate is different than 44.1khz, this makes the loaded samples (which are mainly at 44.1khz) be transposed accordingly.
Anyway, I re adapted my new patches to work with any sample rate now! But the ones released and that I've resent here are still hardcoded to 44.1khz
"When pressing rewind, the location value goes to a small negative number. I gather that that'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])"
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.
Anyway, I understand it won't make much of a difference if you'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're recording samples on the fly, and applying the phase vocoder in it, you cant avoid the latency. I mean, I'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.
Maybe Miller or others have stuff to say, but that's what I got.
Cheers
Alex
2011/9/18 Joćo Pais
<jmmmpais@googlemail.com>
Hi,
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're divided into parts, in case someone doesn't want to answer everything:
- in [pd read-windows], there's the [r $0-insamprate], is supposed to make "sample rate correction". Tracking from where this value comes, it leads to the sample loading subpatch, [pd insample] in the main window. There, the connection doesn't make sense to me:
a) the right outlet of [unpack s f] never should give out something, as [openpanel] only delivers a symbol.
b) so, the patch is hard coded to bang a 44100 to [s $0-insamprate]
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?
And, if both loaded sample and patch have the same sample rate, this variable isn't really necessary, as it will give out 1, right? (which will be multiplied with the transposition, therefore changing nothing).
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's sample rate can be variable?
- - - - - -
When pressing rewind, the location value goes to a small negative number. I gather that that'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])
- - - - - -
Location display (main window, leftest) is in msec of the original sample, right?
- - - - - -
[s location-set] in [pd read-windows]: since this variable gets its value from [r see-loc] (which is banged~), it doesn't need to receive the value from [r location], right?
- - - - - -
[pd hann-window]: the variables window-msec and window-sec don't have receive counterparts. Probably a remain from an old patch?
- - - - - -
The no-detune bang should send 0 to transpo-set instead, right?
- - - - - -
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's happening around? Or I should just go through all the tutorials until I get here?
In case it interests to anyone, I've made a local version of the patch, with all variables and tables preceded with $0.
Thanks again,
Joćo Pais