Hi All,

I apologise in advance if this is not the right place to ask these kind of
questions.

While attempting to get more familiar with the code used by the pvsanal
opcode, more specifically in the /pvsanal.c > generate_frame function (l.
321)/, I stumbled upon something I don't seem to understand, which is the
way the subscript for the analbuf.auxp is calculated while being filled:

*    
    k = p->nI - analWinLen - 1;                 /*time shift*/
    /* Not sure I understand the following */
    while (k < 0)
        k += N;
    k = k % N;
    for (i = -analWinLen; i <= analWinLen; i++) {
        if (UNLIKELY(++j >= buflen))
          j -= buflen;
        if (UNLIKELY(++k >= N))
          k -= N;
         /* *(anal + k) += *(analWindow + i) * *(input + j); */
         anal[k] += analWindow[i] * input[j];;
}*

Additionally, and this is probably part of the reason I don't understand the
above, why are we using cumulative assignment on the last line ? My
understanding of the overlap-add operation (if that is what it is) was that
it is an operation one would do after resynthesis.

Any insights would be helpful!

Thanks,
Darius



--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

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

It is indeed somewhat unusual code to fill an analysis buffer (not mine; 
this is by Mark Dolson aeons ago!), but was done this way (I have always 
assumed) for speed. I must admit I never worked through the code in 
exhaustive detail  - that would probably be a very good exercise!  Note 
the 'anal' buffer is zeroed just before, and that the write doesn't 
always start at the beginning of the block. Much of the code relates to 
the symmetry of the analysis window, hence the -winlen to +winlen logic 
- here "winlen" is half the full length of the window. Speed and 
efficiency outweigh all other considerations, after correctness.

Much of the speed of this pvoc comes from performing "in-place" FFTs - 
the same buffer is used both for input samples and the fft output. In 
our early days in CDP, using an Atari ST (software floating point!), 
pvoc took an hour to process a second of audio, so saving cycles really 
mattered. We used the pre-ANSI "Lattice C" compiler, with very modest 
scope for optimisation compared to modern technology. Pointer arithmetic 
was typically faster than explicit array indexing.

It seems (as I very much hope) Mark Dolson is still around, somewhere in 
Silicon Valley - I wonder if he knows just how extensively his code is 
being used?

Richard Dobson


On 06/11/2018 03:45, DariusPetermann wrote:
> Hi All,
> 
> I apologise in advance if this is not the right place to ask these kind of
> questions.
> 
> While attempting to get more familiar with the code used by the pvsanal
> opcode, more specifically in the /pvsanal.c > generate_frame function (l.
> 321)/, I stumbled upon something I don't seem to understand, which is the
> way the subscript for the analbuf.auxp is calculated while being filled:
> 
> *
>      k = p->nI - analWinLen - 1;                 /*time shift*/
>      /* Not sure I understand the following */
>      while (k < 0)
>          k += N;
>      k = k % N;
>      for (i = -analWinLen; i <= analWinLen; i++) {
>          if (UNLIKELY(++j >= buflen))
>            j -= buflen;
>          if (UNLIKELY(++k >= N))
>            k -= N;
>           /* *(anal + k) += *(analWindow + i) * *(input + j); */
>           anal[k] += analWindow[i] * input[j];;
> }*
> 
> Additionally, and this is probably part of the reason I don't understand the
> above, why are we using cumulative assignment on the last line ? My
> understanding of the overlap-add operation (if that is what it is) was that
> it is an operation one would do after resynthesis.
> 
> Any insights would be helpful!
> 
> Thanks,
> Darius
...

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

Hello Mr. Dobson,

Thank you very much for your extensive and enlightening answer. Knowing the
motivations definitely helps understanding the code structure. I haven't
been working much with pointer arithmetic, consequently it is not something
I can identify right away when exposed to it, especially when it comes to
array indexing and such.

Another problematic aspect for me was the naming of some local variables
used in the frame generation process, such as *got, tocp, fp, ofp*. Are
these names following some naming convention inside/outside the csound world
that I am not aware of ?

Regards,
Darius



--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

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

Wild abbreviations - "tocp" = "[data] to copy", fp = "pointer to float" 
etc. In the days before autocomplete code editors and wide screens, C 
programmers the world over had this habit of using the shortest possible 
names for everything - saves typing. The Csound code is/was replete with 
such things.

Richard Dobson

On 07/11/2018 18:38, DariusPetermann wrote:
> Hello Mr. Dobson,
> 
> Thank you very much for your extensive and enlightening answer. Knowing the
> motivations definitely helps understanding the code structure. I haven't
> been working much with pointer arithmetic, consequently it is not something
> I can identify right away when exposed to it, especially when it comes to
> array indexing and such.
> 
> Another problematic aspect for me was the naming of some local variables
> used in the frame generation process, such as *got, tocp, fp, ofp*. Are
> these names following some naming convention inside/outside the csound world
> that I am not aware of ?
> 
> Regards,
> Darius
> 
> 
> 
> --
> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
> 
> 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

Those of us who were programing in the 1960s and 1970s see nothing odd 
about those names.  Without looking at the code fp sounds like frame 
pointer, ofp is old fp; not sure about the other two but they do not look 
odd.

Computers were smaller and slower, and typing via a perfortr or 
flexowriter was slow as well.

On Wed, 7 Nov 2018, DariusPetermann wrote:

> Hello Mr. Dobson,
>
> ........
>
> Another problematic aspect for me was the naming of some local variables
> used in the frame generation process, such as *got, tocp, fp, ofp*. Are
> these names following some naming convention inside/outside the csound world
> that I am not aware of ?
>
> Regards,
> Darius
>
>
>
> --
> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>
> 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