4 Jul
2016
4 Jul
'16
1:17 a.m.
Le 3 juil. 2016 à 11:52, Fons Adriaensen
<fons(a)linuxaudio.org> a écrit :
On Sun, Jul 03, 2016 at 05:04:17AM +0200, Thomas Brand wrote:
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.
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.
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