well.. that lin/log/exp exercise turns out to be quite a bit more complex than i thought 🙂
orignally i thought i'd take the generated numbers (near the output, where they are already mapped to 0-1) and run them through a [pow], as you would to convert lin behaviour to log or exp.
but this just shifts the position of the output numbers on the slider, which i don't want. i was quite happy with the mapping i had, distributing the generated results evenly. so that needs to stay the same.
what needs to change is the speed at which i travel from one number to the next. and this needs to be a flexible curve.
so here's what i think might work.
when a new number (target value) comes in:
1. check what value we're currently at on the output.
2. calculate the difference we need to bridge (=distance between this current value and target value.)
3. we would then need to add this difference to the current value over time, at a flexible rate.
to determine the wanted curve, the [pow] trick on a [line] output will still work if the line goes from 0 to 1.
so we have the correct curve going from 0 to 1..
if we then multiply the difference-to-be-bridged with this curve, we're going from 0 to the full difference over time, with the wanted slope.
then we can add this to the current value to end up at the target value.
phew.
hope i can get something like that to work reliably..
edit:
well, i cooked something up. the only thing that i couldn't get to work at first was a realtime update of the curve.
it worked fine when waiting for the curve to end, and then have the new one with the new response.
(kinda like the ramp time earlier, hah.)
the problem is that you would either:
- have a jump in value when changing the [pow] factor in realtime (matching the same x position on the new, different curve will yield a different y value), so changing the control would cause skips and not feel smooth.
- have to start a new curve when changing anything (input value, ramp time, or curve response.) this does not cause skips or jumps, because it starts off from the current value, but it causes a whole new ramp to start when you touch a knob. which might be undesirable, especially with longer curves.
- have to start from the current position, and only use the remainder of the ramp time for a new ramp with the new response. this would involve a timer to keep track of how much of the ramp has passed, and i feel it would lead me way too far.
will see where it takes me. for now the reasoning behind the system seems to be correct, so that's that already.