To scale as you describe, try [expr pow($i1/127)*80., 1.04].

Brendan

Thanks Brendan! Although that one doesn't work, it gives me the error "illegal comma" and object stays red. I researched around a bit, and I think what you mean is: [expr pow(($i1/127.),1.04)*80.]? However, with that it's almost linear, and in order to get something that's close to 1.04 with the "classic" scale behaviour you'd need to have an exponent of ~3.5.

This expression gives exactly the same response as using scale with the "Classic exponential compatibility mode" turned OFF. Neither of them have the problem of the jump in the beginning, but actually they give a relatively different kind of response from the "classic" scale one. Unfortunately I prefer the classic scale response for my purposes.

Does anyone have any suggestions what would be the simplest/most CPU-light (I'll have a lot of them in my patch) way of getting a response that's similar to the classic scale behaviour but just without the jump in the beginning? A different expr expression?

I did a small patch that demonstrates the different responses between the classic scale behaviour and the new one. The first preset also shows very clearly the jump in the classic scale behaviour, when using an exponent of 1.02 - it jumps from 0 to 6.6 when going from zero to 1 (when the maximum is 80 and the next value will be 6.73)! This seems really strange, a bug I'd say, so I wonder why it's still not fixed considering that it is, after all the default state (and lot of people don't even know about the classic attribute)...

Here are some thoughts.

Thanks for that jvkr, that's very interesting and useful! (And sorry for the late reply!)

I don't fully understand what's going on in the [expr (pow($f2,($f1/127))-1)/($f2-1)*80] -object, although maybe I don't need to fully understand it in order to use it! :) Using dbtoa with zmap and scale is a good idea (as well as ftom and mtof)!

In the way you've used the [cpuclock], the higher the value is, the more CPU the process uses, right? Meaning that looking up the transfer curve from a buffer is, in fact, by far the most CPU-efficient method? I need to study the abstraction example a bit more, but all in all, very fascinating stuff!

The expression is a variation on the function y=pow(n,x) (n to the power of x). This function, regardless of what the value n is, will always go through the points (0;1) and (1;n). After subtracting 1 and dividing by (n-1) these points become (0;0) and (1;1). From there it is easy to scale from any input range to any output range.

Higher values are indeed more CPU cycles. Storing stuff in buffers is something I started doing with the earliest version of SuperCollider, when I realized that (at that time) a rather large amount of CPU was wasted on calculating the same values over and over again.

Thanks for the info jvkr. Would you normally write the buffers as sound files and read these when the patch is opened, or always generate the buffers anew when the patch is loaded (with an abstraction and patcherargs as in the example you provided)?

One good thing about using buffer for this is that it doesn't matter (CPU-wise) what kind of method is used to write the buffers. For example, as curves were introduced to the function-object in Max 6.07, the function object is now very convenient for creating transfer curves for mapping - especially in S-curves or other cases like that, which get slightly more complex with expr and such. Reading values from the function -object seems to take pretty much as much CPU as the multislider-object, but if these are then stored to buffer, it doesn't matter. For example the inverted S-shape in the example below is something I end up using frequently.

In my case I would generate the data upon load. Some time is lost of course doing this, but it is the most simple approach. Another advantage of using buffers for storing curves is that they can then also be used inside the signal domain.

I hadn't even noticed about the curved functions, thanks for pointing out.