Re: [Faudiostream-users] some questions about code efficiency

Don't have anything to contribute, but I just wanted to say that this looks like really cool work! Steve On Tue, May 31, 2016 at 1:34 PM, Bart Brouns wrote: > > I'm working on my sliding reduce again. > To recap, it's like reduce, but: > - continuously updated output > -

[Faudiostream-users] some questions about code efficiency

I'm working on my sliding reduce again. To recap, it's like reduce, but: - continuously updated output - it uses just two delay lines and two operators for each doubling of the number of samples you want to apply the operator to. So for calculating the sum of the last 65536 samples, you just

Re: [Faudiostream-users] bug in lf_sawpos? (and a possible solution)

Hi Julius, I just tested with moving frequencies and the difference becomes even bigger: (par(i, 1000, my_lf_sawpos(abs((i+10) *lfo) )):>_)/1000 (par(i, 1000, lf_sawpos( (i+10) *lfo )):>_)/1000 take 30 and 65 % respectively, even with the (usually unneeded) abs. Cheers, Bart.

Re: [Faudiostream-users] bug in lf_sawpos? (and a possible solution)

Hi Julius, Here is a screenshot of the output with default slider values, so the frequency modulates between 0 and 110. https://i.imgsafe.org/d635e0c8e8.png I looked at the CPU usage too, and it turns out that on my system at least, my saw is cheaper: (par(i, 1000, my_lf_sawpos(i+10 )