jayrope

1. it seems to not only work in the range defined in the object.

is there a way to overcome/limit this within the object itself?

2. using it's fifth inlet for exponential calculation would oftenly be nice to have a reversed exponential curve instead.

how would you approach this? values lower than 1 for the exponential calculation don't seem to do anything (though there could be a root calculation instead...), when using values higher than 1, then 1.04 (about) already seems to overdrive any useful range.

2b. also when i do scale 0 127 32. 17.000 with exponent 1.03 for a filter, then idealistically i'd need the power affecting reversed, means lower frequencies, when i trigger a filter, should have a finer resolution, that higher frequencies. 

how do you deal with filters needing a finer step grade in lower ranges, than higher ones?

i hope that made any sense, any answers are very appreciated!

1. it seems to not only work in the range defined in the object.
simple example: scale 10 20 20 10
still puts out 9, when inputting 21.
is there a way to overcome/limit this within the object itself?
2. using it's fifth inlet for exponential calculation would oftenly be nice to have a reversed exponential curve instead.
how would you approach this? values lower than 1 for the exponential calculation don't seem to do anything (though there could be a root calculation instead...), when using values higher than 1, then 1.04 (about) already seems to overdrive any useful range.
2b. also when i do scale 0 127 32. 17.000 with exponent 1.03 for a filter, then idealistically i'd need the power affecting reversed, means lower frequencies, when i trigger a filter, should have a finer resolution, that higher frequencies. 
how do you deal with filters needing a finer step grade in lower ranges, than higher ones?

4-63-scale-is-not-limited-to-its-input-range

Use [zmap] when you want the input range to cap the output range. It will keep sending the high or low input value when the input exceeds them.

As for your question regarding the 5th argument to [scale] I tend to use [expr] for this as you can control exaclty how much scaling you want and it can go both ways. This patch scales 0-127 to the audible frequency range.

LH, stupid kind of, but again: i am on 4.63 still, with no way to upgrade currently.

could you post a screen shot of your patch?

the zl tip was very nice, thank you. was not aware of this.

Stupid on my part, I know you use 4.63 anyway and still I manage to forget. I'm sure it won't be the last time it happens either!

ej, can i invoke pow into a scale object itself then?

No worries. In case you wondered what the seemingly random numbers in the [expr]s are they are the floating point midi values of 20Hz and 20000Hz-20Hz (i.e. the range). Explore the maths at your peril.

And as you might of noticed [scale] doesn't let you put anything as helpful as pow2 in place of the final argument.

>[scale] doesn't let you put anything as helpful as pow2 in 

feature request! as soon as i am financially able to buy max 5...

The need to permanently upgrade is a real terror of today.

>[scale] doesn't let you put anything as helpful as pow2 in 
> place of the final argument.

deeply sorry to expose this.
The need to permanently upgrade is a real terror of today.

For what it's worth, here are some abstractions I put together to add my own (intuitive, to me) 5th argument to both the scale and the zmap objects. They're in Max5 though.

Take a look at lp.scampi and lp.scampf from Litter Power.

They optionally allow you to clip/wrap/reflect out-of-range input back into range. And the 5th input is invertible.

Here's a simple patch below demonstrating this. Requires lp.scampf (obviously?) from the Litter Starter Pack. URI at the very bottom of the message.

[4.63] - scale is not limited to it's input range