soft_bypass and faust

[Morphoice]

@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

[aaronventure]

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

[Morphoice]

@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

[aaronventure]

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

[sletz]

@aaronventure Guys, we will not maintain enable/control for backward compatibility , so you are warned !

[aaronventure]

@sletz thanks for letting us know! I'll go with it for now and refactor to ondemand when it ships.

[sletz]

@aaronventure The reason is that maintaining this enable/control feature adds complexity in the compiler that we want now to cleanup.

[aaronventure]

@sletz understandable. The compile time does go up significantly when using these primitive.

[sletz]

@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

[aaronventure]

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

[sletz]

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

[Morphoice]

@sletz said in soft_bypass and faust:

Faust IDE

(grame-cncm.github.io)

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

[sletz]

Yes, the code is easy to adapt.

[sletz]

@sletz Well, I just discovered that https://github.com/grame-cncm/faust/tree/master-dev-ocpp-od-fir-2-FIR. branch is still quite buggy, so no need to rush