Re: [sc-dev] Possible unnecessary calculation in LOOP_BODY_* in DelayUgens.cpp?

[Dan Stowell <danstowell+sc3@xxxxxxxxx>]

Hi all,

As far as I can tell, Tristan is right. I can't see any reason it
would be bad to use "channel" rather than "index" there. I think what
happened is that the "channel" variable was added later (it didn't
exist until commit 2c6ee1ce) and so the simplification wasn't spotted.
(Commit 2c6ee1ce in fact got rid of some of that "hideous" pointer
stuff you mention ;)

It's possible someone profiled it, or someone knew how the registers
are used, and found some low-level speedup, but I'd be very surprised,
since those two variables are incremented at essentially exactly the
same point in the loop.

Dan

2013/11/3 Tristan Strange <tristan.strange@xxxxxxxxx>:
> Weird. My UGen is definitely capable of playing both mono and stereo buffers
> flawlessly and I'm not incrementing a second variable separately. The rate
> of playback etc. aren't affected.
>
> Are you certain the index variable needs to (or even does?)  get shifted on
> in a different manner to channel one?
>
> Is my code likely to fall over on a different system if I don't do this?
>
> Cheer,
> Tris
>
>
> On 3 November 2013 17:20, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx> wrote:
>>
>> 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/
>
>



-- 
http://www.mcld.co.uk

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