I am still working on my composition project and I am having issues with figuring out how to do the right “math” for changing speed of change - things in a non-linear way.
In the below example I try to set the speed of an animation (here: the movement of a small animation on a bigger LED strip) with an int8_t so that it can be both negative and positive in a range between -128 - +127 (i will get this parameter changed during runtime through a MIDI rotary encoder)
What I want to achieve is both very very low speeds which are nearly visible (e.g. move by 1 pixel each minute) as well as very high speeds (e.g. move through about 5000 pixel in a second). I am thinking I need something not linear but either quadratic or with another exponent but I am not very good at this kind of math so maybe someone has an idea how to encode such range in an 8 bit value. Obviously I can only get 256 different values, so the step size will be different between all values.
The below code works but does not have this non-linear part:
Not sure if this will help, but here’s a few versions of an equation that will take input of -128 to 127 and give you back a value of 0-5000. (I’m not positive that’s what you wanted, but maybe this will get you started.)
thanks for your comment - basically yes, this is what i want. I am just concerned about using too much memory and also CPU cycles because I have to do this several times each frame. I found that there are datatypes defined in the FastLED Library (q44 and q62) which seem to implement 8 bit floating point numbers, however when I try to use them I get compile errors.
Those are fixed-point data types, not floating point. They’re basically integers that you decide to interpret as having a certain number of digits after the decimal. More background here:
And I think you’re on the right track. If you want to move as slowly as at 1px/min, you probably want 8 bits of fractional position. That will give you 256 fractional positions per minute, or about four fractions of fade per second. So however you represent “position”, I’d say that the bottom right bits should be for fraction.
thanks for the point with the fixed point aritmetic. makes much more sense to mee now. but also makes clear that there are even distances between all possible values. I will move on for now with that and just use a 16 bit variable. I shall post some demo code tonight, that also includes the smooth palette blending which really works well already.