[PD] I07 vocoder questions

João Pais jmmmpais at googlemail.com
Sun Sep 18 15:15:04 CEST 2011


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,  

- - - - - -

[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

More information about the Pd-list mailing list