now *these* are the kind of threads I like!
Frank's abstraction is quite useful in
[expr ($f1-$f2)*($f4-$f5)/($f2-$f3)+$f4]
I was happy to see this. It gives me more ways to think about this problem.
Also possibly useful could be an even simpler equation to represent a linear scaling operation
[expr ($f1*($f3-$f2)+$f2)]
where $f1 is your floating point input value in range 0-1, $f2 is the intended MIN value and $f3 is the intended MAX value. I use this quite frequently, although possibly less now that I see how Frank approaches it ;)
./d5
ps. Pd patch version of the equation introduced in this mail.
#N canvas 751 398 387 168 10; #X obj 97 74 expr ($f1*($f3-$f2)+$f2); #X floatatom 97 39 5 0 0 0 - - -; #X floatatom 177 39 5 0 0 0 - - -; #X floatatom 260 41 5 0 0 0 - - -; #X floatatom 98 115 5 0 0 0 - - -; #X text 180 19 min; #X text 266 19 max; #X text 19 18 input in range 0-1; #X connect 0 0 4 0; #X connect 1 0 0 0; #X connect 2 0 0 1; #X connect 3 0 0 2;
On May 7, 2006, at 11:13 AM, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
- scale gem/maxlib clash (on a separate thread)
Gem is still a multi-object/single-file object, so it still has the old name clash issues. But you can always use [maxlib/scale] to get that object.
maxlib/scale is trivial to clone with [expr]. I often use attached abstraction for linear scaling.