I realised that my yesterday answer miss the point a little,
so here it is a few linse of complement.
Going back to the Paul comment:
> I can say for sure that, for example,
>Ardour3 has an object called a Processor whose ::run() method
>encapsulates all DSP done within Ardour, but nevertheless it would be
>more or less impossible to do any kind of optimization that looked
>"across" all the Processors in a signal chain (eg. gain, pan, plugins,
>etc, etc).
This is exactly the point: what about having a way to build the 'run' methods
for a class of applications (PD have such a method, jMax have such a method,
many others application have such a methods) that *would* allow cross plugin
optimisations for a certain class of plugins (those written or compiled according
to the engine 'native' rules) and being able to use the other plugins keeping the
glue code run time cost very low thanks to dynamic code generation.
Essentially a generic basic infrastructure using LLVM code generation and optimisation
capabilities.
And by the way, i am not sure to understand the reference to Faust, that is one of the
language/system used to define and assemble DSP algorithms, and to generate plugins,
but it is not a generic container for DSP executions, AFAIK.
Maurizio
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Dec 7 16:15:02 2010
This archive was generated by hypermail 2.1.8 : Tue Dec 07 2010 - 16:15:02 EET