The only true way to bypass computation in gen~ is via if() statements in codebox. But, it’s not always the right thing to do. A couple of reasons:
- The trade-offs on real CPUs of using if() versus computing all paths can be surprising sometimes. Quite often, the if() statement itself can be worse for CPU performance than simply computing both sides of the branch, because of branch prediction and instruction scheduling at machine code level. The general saying is to be careful not to optimize too early – actual behaviour on hardware can be surprisingly different to what is expected.
This gets even more significant when running patches with very small block sizes. The smaller the block size, the more proportional the impact having a bunch of if() (or select etc.) will be – or rather, the less likely benefit of doing it in the first place. And I’ve found with Daisy a lot of the time I can drop block sizes down to around 8 samples with very little impact on CPU cost, and I’m starting to use that as my default for new projects. A lower block size means less IO latency, higher frequency updates of cv inputs etc… at 48kHz, 8 samples is 6kHz, less than a fifth of a millisecond, which is pretty nice. But that means your if() tests would be called every 8 samples of processing, which also limits the benefits of doing it at all.
- Also, especially in an embedded case, the only thing that really matters is the worst case. It’s better to have predictable and relatively constant overhead than a CPU performance that is spiky and varies according to UI parameters. This does tend to be far more predictable in embedded versus desktop computing at least.
So, for these reasons is almost always true that it is better to figure out how to write an algorithm that shares as much code as possible, rather than writing several different algorithms and “switching” between them. That is, try to switch only small fragments of code (such as computing parameters that go into power functions, or mix coefficients, etc.) rather than entire algorithms. And the smaller they are, the more likely it is better just to compute both sides.
Also, if you can change an if() into a mix() then you get to blend between algorithms, rather than just switch between them. Which can be fun to modulate
(Or, if the algorithms are completely independent of each other, then perhaps just use the app selection available in Oopsy?)