Linear mapping from anything to anything

[tulamide]

Let's talk about linear interpolation for a moment, because I recently found a clever little trick, that might be useful for some of you.

Linear interpolation or lerp is pretty straightforward. You get a weighted average of two values. Somewhere between a1 and a2 is ax, and you only know it's 20% of the distance between a1 and a2. So the t-value (the weighted value) is 0.2. It's always between 0 and 1 or 0% and 100%, logically.

Code: Select all

ax = lerp(a1, a2, t) = a1 + t * (a2 - a1)

The formula simply says "multiply the distance between a1 and a2 by our percentage (t) of the way and add the starting point offset".

There also exists unlerp. It does the opposite, of course. You know exactly the value of ax, a1 and a2, but not the t-value.

Code: Select all

t = unlerp(a1, a2, ax) = (ax - a1) / (a2 - a1)

This is basically standard percentage calculation with one additional step. The formula says "remove the starting point offset from ax and divide it by the distance".

But now comes the clever part: I found a formula that combines both to create a function that can map any weighted average to any other weighted average, without having to do the intermediate steps, because the prior fixed t-value is replaced by a dynamic unlerp. A very helpful function. Say, you know a1, a2 and ax and now want to map ax to the equivalent point between b1 and b2.

Code: Select all

bx = remap(a1, a1, b1, b2, ax) = lerp(b1, b2, unlerp(a1, a2, ax)) = b1 + (ax - a1) / (a2 - a1) * (b2 - b1)

Of course, it also works two-dimensional by just solving two times, once for x-axis and once for y-axis.

Note: You don't need remap for mapping your knobs, if they output 0-1. lerp is all you need then. This is more for cases like [-2.72, 0.23] point -1, map to [-0.04, 13.2]

lerp, unlerp and remap are direction-safe. It doesn't make a difference if you use [-2.72, 0.23] or [0.23, -2.72]

Have fun!

[adamszabo]

Very cool!

[trogluddite]

In general, any linear mapping can be reduced to a single multiplication (change of slope) and a single addition (offset at the origin).

For the mapping: ax in a1..a2 -> bx in b1..b2

slope = (b2 - b1) / (a2 - a1)

offset = b1 - (a1 * slope)

bx = (ax * slope) + offset

Although this way is less intuitive to visualise, it can allow a little efficiency boost, especially if mapping at audio-rate. The 'slope' and 'offset' are fixed so long as the input and output ranges are fixed. So you can pre-calculate 'slope' and 'offset' in 'green' (or 'hopped' code), and then reduce the DSP/ASM to just one multiply and one add, avoiding the CPU-hogging division. Here are the old 'Trog Toolz" modules for that (and some sneaky Ruby)...

Linear remap TT.fsm

(1.85 KiB) Downloaded 953 times

[tulamide]

So you can pre-calculate 'slope' and 'offset' in 'green' (or 'hopped' code), and then reduce the DSP/ASM to just one multiply and one add, avoiding the CPU-hogging division. Here are the old 'Trog Toolz" modules for that (and some sneaky Ruby)...

Linear remap TT.fsm

Awesome! I never thought of using it in DSP, as I've seen various other methods from you, Martin and others being used there. But it is good to know that it also serves a role there!
For me, interpolation always was bound to graphics, as I come from game design, where you need ways to constantly and evenly move assets through varying time frames. While the overall rate might be stable 60 fps, as an example, the individual frames will greatly differ (1 frame might only last 1/200 s, while the next lasts 1/30 s), and those different time frames are called delta time (or dt). The time between frames is measured and multiplied with the movement you plan. For example, if something has to move by 10 pixels per second, you would add "10 * dt" on every frame's draw call. But for bound movements you need to interpolate. And there you'd increase t by dt (or any multiplicative of dt). Like "lerp(a, b, t); t+ = dt"
For that the t-value has a very important role, as you interpolate based on delta time (you can't buffer interactive movements).
This issue doesn't appear in DSP of course, as the stream is buffered to provide stable sample rates for the d/a. But there are probably other cases where this is useful?

[newdsp]

Very interesting but this doesn't solve the mapping problem in the Quilcom Chaos Modulation Matrix. If you want to modulate the PAN that goes from 0 to 1 or from -1 to 1 you need one mapping style and if you want to use the same source/modulator/LFO to change the Octaves from 0 to -3 you need a different mapping style.

[Spogg]

Very interesting but this doesn't solve the mapping problem in the Quilcom Chaos Modulation Matrix. If you want to modulate the PAN that goes from 0 to 1 or from -1 to 1 you need one mapping style and if you want to use the same source/modulator/LFO to change the Octaves from 0 to -3 you need a different mapping style.

My knowledge of modulation techniques is really down to what I found, worked out and have seen on pro synths.
In my view it’s up to the target to handle whatever it’s offered and adapt it accordingly.

[newdsp]

In my view it’s up to the target to handle whatever it’s offered and adapt it accordingly.

LOL. That's a good one. That must be a very smart target. Maybe it's an AI target. First it reads your mind and then it re-writes the schematic and the modulation matrix on the fly to come up with all the mapping styles needed. I need one of those too. Where do you find those usually ? LOL. I tried to modulate the pan and it didn't work. It was panning more like forward an back instead of left and right. Then I tried the random modulation on the BASE OCTAVE. That didn't work as needed either because it needs a range limiter. Like a min/max option. It normally goes from +4 to -4 and I needed it to go only betwen 0 and -3. I will try to change it later but it's not clear how is the modulation matrix suppose to know the maximum range and then the new limits.

[tulamide]

(Moderator Note: Two preceding posts have been moved to How do I generate unison voices?.)

This is not the correct thread for that. Newdsp, please create your own thread! (originally said Re: the moved posts.)

[tulamide]

In addition to my last on-topic post:
What was missing was me mentioning that all of the points (in graphics) are dynamic. That's why you can't further optimize the formula there. Well, you can, but it doesn't make sense as it creates overhead. You would need to recalculate slope and offset anyway.

For example, if an asset follows the player, it starts at a1, but a2 will be dynamically changing in regard to the player. Or a moon orbiting a moving planet. Etc.

For DSP, this all would give a headache I assume, as you normaly only get access to the current sample. Optimization makes a lot more sense there as having free access to all exposed variables!