[PD] I07 vocoder questions

[Alexandre Torres Porres]

"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/

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 http://sites.google.com/site/porres/PhaseVoc.zip

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111130/987887a9/attachment-0001.htm>