Hi, I really like the opcode pvsblur, and I wanted to gain a better understanding of exactly what its doing to produce its effect. I was taking a look at the source code in github, but it is pretty dense for someone at my level.

From my understanding what its doing is filling a delay buffer with fft analysis frames, then averaging all the frames within the delay time together, which means that the change of frequency and amplitude over time is slowed. Is this correct?

It is also my understanding that the analysis frames are represented as complex numbers within the pvsblur function, does this mean that to average the frames one has adds these complex numbers together and then divides by number of frames? 

It looks like from the following function this is accomplished for each frequency bin by the for(i = 0; i < NB; i ++). 

Any help is appreciated, really trying to get a good grasp of the whole concept. Thanks!

for (n=offset; n<nsmps; n++) {
	CMPLX *fin = (CMPLX *) p->fin->frame.auxp +NB*n;
	CMPLX *fout = (CMPLX *) p->fout->frame.auxp +NB*n;
	CMPLX *delay = (CMPLX *) p->delframes.auxp +NB*n;
	for (i = 0; i < NB; i++) {
	delay[countr + i] = fin[i];
	if (kdel) {
	if ((first = countr - kdel) < 0)
	first += mdel;
	for (j = first; j != countr; j = (j + framesize) % mdel) {
	amp += delay[j + i].re;
	freq += delay[j + i].im;
	}
	fout[i].re = (MYFLT) (amp / delayframes);
	fout[i].im = (MYFLT) (freq / delayframes);
	amp = freq = FL(0.0);
	}

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Emmett Palaima, Jul 1 2016:
...
> From my understanding what its doing is filling a delay buffer with fft
> analysis frames, then averaging all the frames within the delay time
> together, which means that the change of frequency and amplitude over time
> is slowed. Is this correct?
>From reading the source code you pasted in below, it looks like that is it. The frames store complex numbers merely to encode two values in a single variable: the re part being the frequency and the imaginary part being the amplitude (.re and .im in the relevant loop). It's a bit like a digital lowpass filter, as I understand it. Changes get averaged out a bit. So no high, short peaks, but slower "waves".

Take it with a grain of salt, since I'm no good mathematician. :)
...

Ta-ta,
----
Ffanci
* Homepage: https://freeshell.de/~silvain
* Twitter:  http://twitter.com/ffanci_silvain
* GitHub:   https://github.com/fsilvain

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Emmett Palaima, Jul 2 2016:

> Thanks to both of you for your help, that certainly clears up a lot. I was
> also wondering what it means in this case for the frequency component of
> the bins to be averaged, since I thought that the frequency of each bin was
> fixed beforehand by ifftsize in pvsanal.
Emmett, one bin is not equal to exactly one frequency, but a small frequency band. So the ifftsize of opcodes like pvsanal gives you a a frequency resolution:
ifreqresolution = ifftsize / sr
sr is the samplerate.

I believe that in classic fft the frequency of a bin would be slightly incorrect. The tradeoff is between a very good frequency resolution with lots of bins. But the finer the difference between the frequencies the longer the analysis will take and so amplitude changes will get lost. If you'd want a resolution of 1 Hertz, it would take one second to analyse and that would also be the resolution for amplitude changes.

Sorry for rambling, but I hope it does help.
...

Ta-ta,
----
Ffanci
* Homepage: https://freeshell.de/~silvain
* Twitter:  http://twitter.com/ffanci_silvain
* GitHub:   https://github.com/fsilvain

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Yes, and I can add to this.
The STFT on its own can give us amplitudes and phases for each bin. The PV takes phase diffs between consecutive frames and that is a the frequency detected at each bin.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 2 Jul 2016, at 07:33, Ffanci Silvain  wrote:
> 
> Emmett Palaima, Jul 2 2016:
> 
>> Thanks to both of you for your help, that certainly clears up a lot. I was
>> also wondering what it means in this case for the frequency component of
>> the bins to be averaged, since I thought that the frequency of each bin was
>> fixed beforehand by ifftsize in pvsanal.
> Emmett, one bin is not equal to exactly one frequency, but a small frequency band. So the ifftsize of opcodes like pvsanal gives you a a frequency resolution:
> ifreqresolution = ifftsize / sr
> sr is the samplerate.
> 
> I believe that in classic fft the frequency of a bin would be slightly incorrect. The tradeoff is between a very good frequency resolution with lots of bins. But the finer the difference between the frequencies the longer the analysis will take and so amplitude changes will get lost. If you'd want a resolution of 1 Hertz, it would take one second to analyse and that would also be the resolution for amplitude changes.
> 
> Sorry for rambling, but I hope it does help.
> ...
> 
> Ta-ta,
> ----
> Ffanci
> * Homepage: https://freeshell.de/~silvain
> * Twitter:  http://twitter.com/ffanci_silvain
> * GitHub:   https://github.com/fsilvain
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>       https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

el 2016-07-02 a las 08:33 Ffanci Silvain escribió:

> frequency resolution: ifreqresolution = ifftsize / sr sr is the
> samplerate.

or the other way around... :-)

actually, frequency resolution = sr/N, being N the number of samples
acquired. that means that strictly speaking the resolution does not depend
on the DFT size itself, but on the window size. increasing the DFT size
with zero padding won't increase resolution (you'll get a better
definition, though).

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here