The first lines of code have a xline controlling the frequency , since the xLine is a unipolar signal , I can just addd a value of 5000 going to 10 added to the initial frequency value , all good
Using a LFNoise , which is a bipolar signal , I have to use a rather high multiply value for filter modulation , however going to high ( over 5000 ) clips the filter becasue the filter frequency is going negative )
So I wan’t to use an upper clipping limit for the lfo multiply amount.
Here I used a save value of 500 , everyhting over it will clip te filter
Replacing the lfo with saw , I can get the multiply amount as high without clipping the filter , unless initial filter frequency is also set to low value
Hey, there’s a shortcut to do this mapping: UGen::range
// 5hz LFNoise, output between 100 and 10000 Hz
// alternative using an exponential scale since we are dealing with freqs
By the way, it is now not recommended to use UGens add and mul arguments. MulAdd (used internally by .range, and also when you do sums and multiplications) is a more efficient alternative.
If you want to scale LFNoise manually (by adding and multiplying), I suggest to first make it positive and then to scale it to the range: LFNoise1.kr(5) + 1 * 10000 / 2
I don’t have a precise insight for why this works as expected (no negatives) while your example with mul: and add: doesn’t. Sounds like something in the order of operations (maybe add is performed after mul by LFNoise1?)… but if you write them explicitly like here you can control that
Extra: there is also a .clip function, for all your clipping needs:
// 5hz LFNoise, output between 100 and 10000 Hz, clipped between 500 and 1000 Hz
It’s true that there’s some movement away from using mul and add, but the reason is to move UGen range scaling away from positional arguments toward concrete math operations. In fact, gentleclockdivider already got burned by putting a mul in the wrong argument slot.
My preference for range mapping is range or exprange first, then linlin or linexp, lastly falling back to math operators if nothing else fits. I hardly use mul and add arguments at all anymore.
The SynthDef builder is pretty good at finding a * b + c constructions and optimizing them to MulAdd(a, b, c). Efficiency shouldn’t be a concern (unless we find cases that the optimizer doesn’t handle – if the optimizer is working correctly, there should be no need to invoke MulAdd directly).