soft_bypass and faust

Morphoice

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

Lindon

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

Christoph Hart

@Lindon nope it‘s bypassed.

Morphoice

@Christoph-Hart thanks for clarifying! So this is the way to go until faust introduces the ondemand primitive. Perfect!

Morphoice

@Lindon I was under the same impression as everything within faust is always processed, it can produce quite some overhead

aaronventure

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

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

soft_bypass and faust

Faust IDE

14

1.7k

11.8k

102.6k