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 <b...@magnetophon.nl> wrote:
>
> 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 need
>   just 32 delay lines and 32 plus operators.
> - You can still continuously vary the number of samples to compute at
>   runtime.
>
>
> The current implementation works perfectly and is very cheap.
> The downside is that you need to provide a value to signify 'disabled'.
>
>
> I found a workaround for that, but it is using much more CPU then
> expected.
>
> To explain the problem, here is a much simplified version of what I'm
> doing:
>
>
> process(x) =
> example(size,maxSize,x);
> // example2(size,maxSize,x);
>
> maxSize = 4; // for block diagram
> // maxSize = 256; // for testing
>
> size = (vslider("size", 0, 0, maxSize, 1));
>
> example(size,maxSize,x) =
> par(i, maxSize, x@i:useVal(size,i))
> : combine(maxSize);
>
> example2(size,maxSize,x) =
> par(i, maxSize, x@i) <:
> par(i, maxSize, combine(i+1),nothing(maxSize-i-1))
> :par(i, maxSize, _*((i+1)==size)):>_
> with {
>   nothing(0) = 0:!;
>   nothing(1) = !;
>   nothing(n) = !,nothing(n-1);
> };
>
> combine(1) = _;
> combine(2) = +;
> combine(n) = (combine(n-1),_) :+;
>
> useVal(target,current) = _*(current<target);
>
>
> It's much easier to understand visually:
>
> example:
> https://i.imgsafe.org/db6228a807.png
>
> example2:
> https://i.imgsafe.org/db63c1d8d7.png
>
> The second strategy doesn't make sense for + or -, but to use the first
> one a for min or max you need to replace the *1 and *0 with _ and
> 'disabled val'.
> You cannot use strategy 1 with an arbitrary operator at all, you need
> strategy 2.
>
> So, I implemented it:
> https://github.com/magnetophon/faustCompressors/blob/master/slidingReduce.lib#L95
>
>
> There are a few problems though:
>
> -I thought that parts of a faust program that don't have state can be
> turned off at runtime when they are not needed for the result.
> Afaik only one of the blocks of summers in example2 should be running at
> one time. Going by CPU usage, it isn't.
>
> - With a fixed number of samples, the CPU usage should be identical. It
>   isn't.
>
> - With a fixed number of samples, the compiler should be able to figure
>   out that only one block of summers is needed, and not spend time
>   compiling the others. It doesn't, example2 takes ages to compile, even
>   with a fixed nr of samples.
>
> Thanks for listening!
>
> Bart.
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> _______________________________________________
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users

Reply via email to