[Jack-Devel] graph simplification using mathematics?

[Stéphane Letz]

>> 
>> 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