Yes, thats what I was looking for. Using f(x)=x^slope is not only always monotonically increasing and adjustable, it is also trivial to invert (x^(1.0/slope)).
Indeed, hadn't thought of it in terms of inversion, but I needed that for implementing logscale knobs for the new Processor parameters (cannow be found in ebeast/b/pro-input.vue), It turns out slope is determined by specifying a logscale center like so:
// Determine exponent, so that:
// begin + pow (0.0, exponent) * (end - begin) == begin ← exponent is irrelevant here
// begin + pow (0.5, exponent) * (end - begin) == center
// begin + pow (1.0, exponent) * (end - begin) == end ← exponent is irrelevant here
// I.e. desired: log_0.5 ((center - begin) / (end - begin))
Example in gnuplot:
begin=32.7; end=8372; center=523; e=log((end-begin) / (center-begin)) / log(2)
print e; set logscale y; plot [0:1] begin + x**e * (end-begin), center
I can think of only one reason to use x^3 rather than the generic x^slope: if we had all properties automatable and some value ramp for portamento glide, then we would possibly want to compute the mapping from input modulation interval [0,1] to portamento glide at every sample (for this particular module it doesn't matter, but there may be time parameters that can be tweaked at runtime like compressor-attack-ms or adsr-attack-ms or delay-ms). Modulation should in general use a non-linear mapping from control value to dsp parameter, I think the obvious choice would be to use the same mapping like for the ui slider.
I have just added logscale mappings to the Attack/Decay Env in Blepsynth in milliseconds: min=0, max=8000, logcenter=1000
With the above formulas, that results in e=3: 0 + pow (x, 3) * 8, i.e. slope=3; f(x)=8*x^slope;
But for the cutoff frequency, a completely different center was needed, so the slope there is indeed different, more like 4.75 - 5.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.