5 Jul
2016
5 Jul
'16
10:09 a.m.
>
> And FAUST comes with one complication in this area - there is no "turn
> off" switch. To "bypass" something in FAUST, you compute it anyway,
and
> then multiple the output by zero. Although this works, it is not a viable
> solution for complex synths - Sorcer[1] only has 3 wavetables
> because adding more means more CPU per voice.
>
On/Off and Bypass would be parameters. I'm not sure i get the scenario you
describe, but "off" would be a switch at the front that doesn't do
anything with incoming data and does output a fixed zero while "bypass"
would act like a bridge, just feeding input to output (*1 if you like).
> Don't get me wrong - I really like FAUST, and it is extremely powerful
> for certain use cases - but building DAWs or "configurable" audio
> processors is not one. Building DSP blocks that can be used by a DAW or
> configurable audio processors is its strength - and its awesome for that.
>
There is an experimental branch on Faust GIT called "master-with-mute » which allows
to « dynamically bypass » computation of parts of the graph.
DAW would be a set of widgets, controls and views
"orchestrating" the
blocks. I know that's too much simplified still not completely crazy to
think about IMHO.
Well in this community you have 1) lots of experienced C/C++ developers that have
developed tools for years… with the power and limits of the kind of imperative languages
they use. And you have 2) some crazy people that try (for years also..) to approach the
problem with alternate visions, like : how can functional languages help? How can dynamic
compilation help? how can partial evaluation help ? (to name a few…)
Since people from 2) cannot solve everything for now at least, people from 1) say that in
the end, you are going to have to use the good old tools to solve the problem… ((-;
But the 2) people stil think that for sure : this is not completely crazy to think about…
Stéphane