soft_bypass and faust
-
Ahoi! Is faust inside a soft_bypass node bypassed or processed when the node is disabled? I can't see any cpu improvement when disabling the node...
-
@Morphoice said in soft_bypass and faust:
Ahoi! Is faust inside a soft_bypass node bypassed or processed when the node is disabled? I can't see any cpu improvement when disabling the node...
my understanding is that Faust is always running no matter what is sent to it...
-
@Lindon nope it‘s bypassed.
-
@Christoph-Hart thanks for clarifying! So this is the way to go until faust introduces the ondemand primitive. Perfect!
-
@Lindon I was under the same impression as everything within faust is always processed, it can produce quite some overhead
-
@Morphoice You can still pipe individual expressions into the control(bool) primitive which is undocumented (it was an attempt to create this sort of processing segmentation years ago but they abandoned it because it clashed with Faust semantics, if I understood correctly).
It still works, though.
process = _, _ : (si.bpar(2, filter) : control(filterEnabled));
Although I found it leaves a little bit of performance on the table for especially hungry algorithms, so if you're gonna be repeating your Faust dsp program many times inside the network, you're introducing unnecessary CPU overhead.
For stuff like filters, it's great. An algo that eats 3-10% of the realtime CPU, you're leaving 0.1% on the table (those are my readouts for my specific usecase).
-
@aaronventure I don't really get how this works but the filter indeed is the main cpu intensive thing that I need to improve in my synths... mostly at extreme levels there are a lot of nonlinearities I have to bring in which dont make much sense to be calculated if not really needed at normal levels
-
@Morphoice you out anything you want to be able to bypass into parentheses and then pipe it into control(bool). That's the syntax, where bool is a variable which can be linked to your interface parameters or anything else like filterGain > 0.
-
@aaronventure jesus. that's on demand functionality right there - it even seems to work with non bool, as long as its >0 it's processed, otherwise not!? how brilliant is that
import ("stdfaust.lib"); gain = hslider("gain",1,0,1,0.01); process = os.osc(440) * gain : control(gain) <:_,_;
you won't happen to know if this is safe to use or will be deprecated at some point? I assume they left it in for backwards compatibility
-
@Morphoice there are some library functions that use it so it's unlikely to get removed before ondemand is introduced. That's my read, anyway.
Faust maintainers warned against relying it on as it might not work every time, but I found it perfectly reliable whereas enable() was somewhat finicky.
It still won't let you downsample processing like ondemand is planned to, and it won't completely eliminate the processing, but yeah it's there and you can use it now. I surely do.
-
@aaronventure Guys, we will not maintain
enable/control
for backward compatibility, so you are warned !
-
@sletz thanks for letting us know! I'll go with it for now and refactor to ondemand when it ships.
-
@aaronventure The reason is that maintaining this
enable/control
feature adds complexity in the compiler that we want now to cleanup. -
@sletz understandable. The compile time does go up significantly when using these primitive.
-
@aaronventure Note that in case you can directly compile Faust + LLVM, the WIP branch with
ondemand
working is here: https://github.com/grame-cncm/faust/tree/master-dev-ocpp-od-fir-2-FIR.We are interested in feedback, in case you HISE guys can test it
-
@sletz how would this work with the windows version which relies on the installer installing to the default path on C?
If we go down that route I'm sure there'll be a bunch of questions about it; on macOS it should be pretty easy (swapping the folder contents).
With that in mind, do you think you can put a compiled beta/alpha release here (in case the official repo is not a good place for it) so we can all just dive in without setting up a separate environment just for this compilation?
I'd love to test it out. I have a pretty beefy algorithm in the works which is currently segmented into something like 16x6x2 Faust.dsp programs precisely because I need bypassing and branching. I'd test it out extensively and try to make it all work in a single program using ondemand and report any issues and performance results.
-
@aaronventure Trying to create binaries on the GitHub CI, but still some problems to solve.
In the meantime you can possibly try the Faust IDE Ondemand aware version: https://grame-cncm.github.io/faustide-od/
-
@sletz said in soft_bypass and faust:
on the user end, it should be fairly trivial to replace the control primitive with the ondemand syntax once it's out, shouldn't it? I've only read Yann's specs on github so far but it seems pretty straight forward
-
Yes, the code is easy to adapt.