Yes, this moves the read pointer ahead. If the signal is mono, the two variables will have the same value, but in a multi-channel buffer, the samples are interleaved and the index needs to increase at a different rate.
Josh
/*
Josh Parmenter
www.realizedsound.net/josh
*/
_______________________________________________
> On Nov 3, 2013, at 7:13 AM, Tristan Strange <tristan.strange@xxxxxxxxx> wrote:
>
> Hi all,
>
> I've just noticed that in the LOOP_BODY_* macros in DelayUGens.cpp 2 variables (index and channel) are incremented when iterating over channels and writing stuff out?
>
> Here's the excerpt from LOOP_BODY_4 where it occurs:
>
> int32 index = 0; \
> float fracphase = phase - (double)iphase; \
> for (uint32 channel=0; channel<numOutputs; ++channel) { \
> float a = table0[index]; \
> float b = table1[index]; \
> float c = table2[index]; \
> float d = table3[index]; \
> OUT(channel)[SAMPLE_INDEX] = cubicinterp(fracphase, a, b, c, d); \
> index++; \ // <- !!!!! is index really neccesary? !!!!
> }
>
> In the Ugen I've been writing I've managed to get things working in a manner similar to this:
>
> float fracphase = phase - (double)iphase; \
> for (uint32 channel=0; channel<numOutputs; ++channel) { \
> float a = table0[channel]; \
> float b = table1[channel]; \
> float c = table2[channel]; \
> float d = table3[channel]; \
> OUT(channel)[SAMPLE_INDEX] = cubicinterp(fracphase, a, b, c, d); \
> }
>
> Is this something to with getting the code working on odd architectures or something? I usually avoid C++ as much as possible so can only imagine this is something to do with shifting the table pointers along safely or some other similarly hideous thing.
>
> Is there a reason for them being there or have they just been missed?
>
> Cheers,
> Tristan
>
>
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/