but when we use the slider with the log function, we're actually doing an inversion of this graphs I just posted. In other words, what we do is the first formula that is actually from the code. So using that formula was actually right to begin with.
Check my patch attached now 2014-03-18 17:05 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > and as I was checking before, not too far from raising to the power of > 0.25 (thicker line in the graph from the picture attached) > > > 2014-03-18 16:48 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > > the solution is as I thought, to just invert the given formula in the >> code. Someone helped me with the math, is something like >> >> expr ln($f1 / 1.27) / (((log(127 / 1.27) / 1.27)) * 0.01) >> >> here's a patch attached >> >> I'm finally gonna check what kind of curve this thing gives :) >> >> Thanks everyone >> >> Cheers >> >> >> 2014-03-18 5:13 GMT-03:00 Jonathan Wilkes <jancs...@yahoo.com>: >> >> No, the code I ported is from vslider_set and vslider_draw_update (might >>> be different in Vanilla). >>> >>> In vslider_bang, math is done to output the proper value. Without >>> looking at the code I would have guessed vslider_bang simply outputs a >>> stored value like [float] does. Then just do math to set the slider >>> position or calculate a new stored value from mouse input. >>> >>> -Jonathan >>> >>> >>> On Monday, March 17, 2014 1:21 AM, Alexandre Torres Porres < >>> por...@gmail.com> wrote: >>> Hi Roman. This is turning out trickier than I thought. A friend >>> explained the code to me and got to the following equation, with min/max >>> values as 0.01 and 1 respectively. >>> >>> [expr 0.01 * exp((log(1 / 0.01) / 0.01) * $f1 * 0.01)] >>> >>> For what I've checked, it seems to behave like your patch. But it >>> doesn't do the trick I'm looking for yet. I sent a patch earlier, and I'm >>> sending it back again. >>> >>> The goal is to connect a linear slider to an [expr] (with this so called >>> "log" function) and then to another linear slider. The idea then is that >>> this second slider behaves as one that was set as being "log". >>> >>> In the patch attached I was able to emulate it poorly with [pow 0.25], >>> but that was before reaching the list. See that if I use this expr function >>> from the code or your patch it presents quite a different behavior. >>> >>> maybe it is some sort of inversion of this equation, not sure. >>> Apparently this code converts the "log" function values to linear and I'm >>> hoping to get the exact opposite. Got it? >>> >>> Thanks for looking into this >>> >>> >>> 2014-03-12 4:38 GMT-03:00 Roman Haefeli <reduz...@gmail.com>: >>> >>> On Don, 2014-03-06 at 21:37 -0300, Alexandre Torres Porres wrote: >>> > hi folks, out of curiosity, what's the exact log function used in the >>> > slider? I'd like to emulate it. >>> >>> I am not sure, if this is what you want. It converts the incoming linear >>> range between 0 and 1 to a logarithmic range specified by $1 and $2, >>> respectively by the second and third inlet. They behave like the lower >>> and upper bound specified in the [vslider]/[hslider] classes. >>> >>> https://raw.github.com/reduzent/netpd2-patches/master/abs/rh_scalelog.pd >>> >>> >>> Roman >>> >>> >>> >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >>> >> >
log.pd
Description: Binary data
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
