Hello, I'm wondering if anyone has some pointers in changing the order of different fx processes inside one gen routine.

Optimally I would like to not duplicate any processes but rather change the order in which they are send to/received from. The only way I currently see it "might be" possible is by creating some form of function that uses multiple History Objects to function as send and receive. So for routing between four FX inside the gen routine I would need to introduce a four sample overall delay.

Any tips would be highly appreciated! Thanks

Hello, I'm wondering if anyone has some pointers in changing the order of different fx processes inside one gen routine.

Optimally I would like to not duplicate any processes but rather change the order in which they are send to/received from. The only way I currently see it "might be" possible is by creating some form of function that uses multiple History Objects to function as send and receive. So for routing between four FX inside the gen routine I would need to introduce a four sample overall delay.

Any tips would be highly appreciated! Thanks

Hello, I'm wondering if anyone has some pointers in changing the order of different fx processes inside one gen routine.

Optimally I would 

building-an-fx-routing-system-purely-in-gen

Three possible methods, with different pros and cons:

1) Use switches and insert a history one one of the routes. Pros are that this can minimize latency (only N-1 samples of history per N fx in the worst case), cons are that this doesn't scale well for many fx. I recommend this if you only have a small number of possible fx topologies. In particular, you can even eliminate the history if one of the fx is a [delay] operator with @feedback 1. 

If you use [mix] instead of [switch], you can crossfade between routings (though this will create audio feedback loops!)

Screen Shot 2022-01-15 at 2.19.35 PM.png

2) Use sample frames of a [data] to read/write intermediate results between each fx. Pros are that this scales better to more complex numbers of fx and possible routings (including self feedback etc.), and could be turned into a full matrix mixer if you wanted. Cons are that this will always have 1 sample of latency per fx on all possible routes. (Though you could reduce this somewhat by writing the equivalent in codebox, where you have more control over the order of peeks and pokes.) I recommend this method if you have more fx or possibly complex routings and mixing.

Screen Shot 2022-01-15 at 2.18.54 PM.png

3) Write the whole thing in codebox. Pretty simple for the 2fx case, but will need several larger if/else statements for more fx. Pros are that latency is completely removed, as you have complete control over the order of operations. Cons are that this method is almost certainly more CPU hungry, unless the fx themselves are trivially simple as below. (This may be counter-intuitive to folks expecting that codebox will be more efficient. The reason here is that if/else is generally expensive on modern CPUs if the body of code inside the if/else blocks is complex, due to branch prediction/cache misses etc. Also, this method may lead to code duplication in the machine code.)

I would only recommend this method if the functions are really simple, like waveshapers, and definitely definitely not for memory-intensive fx like reverbs).

Screen Shot 2022-01-15 at 2.18.14 PM.png

Finally, one thing you might want to consider is whether to apply any anti-clicking methods when changing the routing. A quick duck to zero and back over a millisecond or two, applying the routing change while the duck is at zero, should eliminate the worst of it; the same ducking parameter can be used as a multiplier to all the fx inputs for example. 

1) Use switches and insert a history one one of the routes.  Pros are that this can minimize latency (only N-1 samples of history per N fx in the worst case), cons are that this doesn't scale well for many fx.  I recommend this if you only have a small number of possible fx topologies. In particular, you can even eliminate the history if one of the fx is a [delay] operator with @feedback 1. 

If you use [mix] instead of [switch], you can crossfade between routings (though this will create audio feedback loops!)

2) Use sample frames of a [data] to read/write intermediate results between each fx.  Pros are that this scales better to more complex numbers of fx and possible routings (including self feedback etc.), and could be turned into a full matrix mixer if you wanted. Cons are that this will always have 1 sample of latency per fx on all possible routes. (Though you could reduce this somewhat by writing the equivalent in codebox, where you have more control over the order of peeks and pokes.)   I recommend this method if you have more fx or possibly complex routings and mixing.  

3) Write the whole thing in codebox. Pretty simple for the 2fx case, but will need several larger if/else statements for more fx. Pros are that latency is completely removed, as you have complete control over the order of operations. Cons are that this method is almost certainly more CPU hungry, unless the fx themselves are trivially simple as below.  (This may be counter-intuitive to folks expecting that codebox will be more efficient. The reason here is that if/else is generally expensive on modern CPUs if the body of code inside the if/else blocks is complex, due to branch prediction/cache misses etc. Also, this method may lead to code duplication in the machine code.)
I would only recommend this method if the functions are really simple, like waveshapers, and definitely definitely not for memory-intensive fx like reverbs). 

Finally, one thing you might want to consider is whether to apply any anti-clicking methods when changing the routing. A quick duck to zero and back over a millisecond or two, applying the routing change while the duck is at zero, should eliminate the worst of it; the same ducking parameter can be used as a multiplier to all the fx inputs for example. 

Graham

Crap -- I gave a pretty lengthy response, and then accidentally deleted it by hitting the wrong button! Ok, trying again, will keep this short though.

1) Simple switches, with at minimum N-1 history objects for N fx. Latency can be kept pretty minimal on a preferred path. Doesn't scale well if you want many possible fx topologies. E.g;

Screen Shot 2022-01-15 at 2.42.32 PM.png

2) Store intermediate results in a [data]. Great if you want to support many possible topologies, but N fx means N samples latency. Can be scaled up to a full-on matrix mixer. Simple example:

Screen Shot 2022-01-15 at 2.45.58 PM.png

3) Use a codebox to control order of operation via if/else statements. Advantage here is that you can ensure zero latency, but the disadvantage is that the CPU cost is likely higher, both because of the general overhead of if/else (branch prediction/cache misses on the CPU) as well as a greater likelihood of duplication in the generated machine code. I would only recommend this option if the fx routines are very simple, and minimizing latency is the highest priority. Definitely not for memory intensive routines such as reverbs! Example code:

Finally, I suggest some kind of anti-clicking (e.g. duck all fx inputs to zero and back over a few ms, applying the topology change when the duck is at zero).

Crap -- I gave a pretty lengthy response, and then accidentally deleted it by hitting the wrong button! Ok, trying again, will keep this short though.  

1) Simple switches, with at minimum N-1 history objects for N fx. Latency can be kept pretty minimal on a preferred path.  Doesn't scale well if you want many possible fx topologies. E.g;

3) Use a codebox to control order of operation via if/else statements. Advantage here is that you can ensure zero latency, but the disadvantage is that the CPU cost is likely higher, both because of the general overhead of if/else (branch prediction/cache misses on the CPU) as well as a greater likelihood of duplication in the generated machine code.  I would only recommend this option if the fx routines are very simple, and minimizing latency is the highest priority. Definitely not for memory intensive routines such as reverbs! Example code:

y = in1;
if (which) {
	y = fx1(y);
} else {
	y = fx2(y);
}
if (which) {
	y = fx2(y);
} else {
	y = fx1(y);
}
out1 = y;

Finally, I suggest some kind of anti-clicking (e.g. duck all fx inputs to zero and back over a few ms, applying the topology change when the duck is at zero). 

- for the [history] paths, if the fx is a [delay] and you don't need sub-sample delay times, you won't need the [history] as [delay @feedback 1] can also handle feedback paths. 

- you could use some of these techniques to choose between multi-operator FM topologies. 

- in some cases, it might be useful to crossfade rather than switch between algorithms. You could use [mix] instead of [switch] for example, or add @interp linear to [peek], but watch out for feedback! 

- for some topologies you could provide additional tap outs, e.g. for fx1->fx2 you could have tap outs at both fx2 as well as fx1. Again, blending between these might be fun.

Additional thoughts:
- for the [history] paths, if the fx is a [delay] and you don't need sub-sample delay times, you won't need the [history] as [delay @feedback 1] can also handle feedback paths. 
- you could use some of these techniques to choose between multi-operator FM topologies. 
- in some cases, it might be useful to crossfade rather than switch between algorithms. You could use [mix] instead of [switch] for example, or add @interp linear to [peek], but watch out for feedback! 
- for some topologies you could provide additional tap outs, e.g. for fx1->fx2 you could have tap outs at both fx2 as well as fx1. Again, blending between these might be fun.  

Hey Graham, thanks for the extensive reply! 

I have all my code running in a single Codebox instance, using require to import all relevant FX routines. 

My current solution is basically what you suggested here:

While this overall works well I have issues with some duplicated FX function instances. I noticed that some objects like history have strange behavior when used this way. For example when having an abstraction called "fx1reverb" loaded in both if statements above, there will be feedback loops happening, although the function should be only active in one of the two if statements.

The only way to fix this error for me is, to "wrap" these fx functions into another set of functions called "fx1reverb1" "fx1reverb2" at the moment and have them defined individually in each if statement.

Also in generally using the if method above, makes changing the order of modules not smooth and can cause clicks. I would definitely like to go down the route of having some form of history / mix setup that is used to drive the input/output logic of each FX, while having them only defined once and running through.

I think the example 2) you showed will be my best bet - I will do some more digging today and try to reproduce this in a codebox setup. Thanks a lot!

Hey Graham, thanks for the extensive reply! 

 I have all my code running in a single Codebox instance, using require to import all relevant FX routines.  

My current solution is basically what you suggested here:

While this overall works well I have issues with some duplicated FX function instances. I noticed that some objects like history have strange behavior when used this way. For example when having an abstraction called "fx1reverb" loaded in both if statements above, there will be feedback loops happening, although the function should be only active in one of the two if statements.

The only way to fix this error for me is, to "wrap" these fx functions into another set of functions called "fx1reverb1" "fx1reverb2" at the moment and have them defined individually in each if statement.

Also in generally using the if method above, makes changing the order of modules not smooth and can cause clicks. I would definitely like to go down the route of having some form of history / mix setup that is used to drive the input/output logic of each FX, while having them only defined once and running through.

I think the example 2) you showed will be my best bet -  I will do some more digging today and try to reproduce this in a codebox setup. Thanks a lot!


Building an FX Routing System purely in Gen