[Jack-Devel] graph simplification using mathematics?

[Stéphane Letz]

> Le 3 juil. 2016 à 11:52, Fons Adriaensen <fons at linuxaudio.org> a écrit :
> 
> On Sun, Jul 03, 2016 at 05:04:17AM +0200, Thomas Brand wrote:
> 
>> Given that a processing graph doesn't change constantly (except in some
>> special cases), i'd imagine to kind of "freeze" the plugins setup to a
>> single instance to gain more room per cycle. Maybe this is just a pipe
>> dream. Having all involved DSP in a declarative text language instead of
>> BLOBs. Whole DAWs could be built like this. As i said, just a pipe dream
> 
> Keep in that in all but the simplest algorithms, audio processing doesn't
> just involve calculations on samples, but also logic, maintaining state,
> and in general things that don't happen at the audio sample rate but have
> their own independent timing which isn't regular and can't be predicted.
> Faust isn't particularly good at any of that.

This is not by itself a limitation of this kind of approach : Faust (for now) is mainly designed to code synchronous mono-rate DSPs and the purpose of my previous mail was to explain that some categories of graphs where each node is coded in Faust can be automatically rewritten (and the compiled) into a single equivalent (possibly more efficient) node. No more no less.

> 
> In theory all of that could be expressed in a 'formula', but the complexity
> of such a formula will explode exponentially unless you express it as a
> chain or graph of separete operations with no or limited interaction. And
> then we are back where we started. 
> 
> You may think that running the entire combined algorithm sample per sample,
> avoiding all intermediate buffers, would be more efficient than having 
> separate modules which communicate by passing blocks of samples between
> them. But that is NOT the case. Short loops using a small set of variables
> make much better use of CPU registers and the cache, and will be faster.
> 
> In other words, even if it would practically possible to do what you
> suggest, nothing will be gained, on the contrary.
> 
> Ciao,
> 
> -- 
> FA

The point can be : what kind of language and tools do we use to code our audio programs : the functional paradigm has some quality by itself that can help in some specific areas.

Stéphane