After all Ben has done to make it blazing fast, which is commendable, I’m interested in slowing it way down…patterns that slowly change over minutes, hours, even days. I’m not looking for a code level solution yet, but am interested in the range of strategies one might use to accomplish this goal. Im new at this and would love to hear how some of you conceptualize this problem.
Would it be possible to write code for a global speed control, similar to the global brightness control in PB?
If you are asking yourself why, think of a wall in you home that might change colors slowly with time of day, temperature, activity level, or whatever?
You could tie a global speed variable to an A/D input on the sensor expansion board, and tie that input to just about anything: thermistor, potentiometer, photodiode, pulse monitor, barometer, ultrasound proximity detector, capacitively coupled sensors (like a theremin) , explosive gas detector, defcon meter, whatever.
And, I don’t see any reason why the speed (or time constant) variable can’t be made ludicrously slow, I’ve slowed down most of the open-source patterns on my own art.
With a value of 1, you get a cycle time of about 65.5 seconds. The argument to the time function can be a large number, up to 32767 and would give you a cycle time around 24 days.
You can also use a global coefficient to control all calls to time(), like time(.1 * speed) but if you tie it to an analog input or the ADC, you will need to add some hysteresis. Different values will change the output dramatically, probably not too bad when you are dialing it in, but a source with some noise on it would cause animations to glitch violently.
Thank you for the ideas and the upper limits on the time function. Very useful. 24 days will be plenty!
I’m pretty new to programing in general. I understand how the argument to the time function changes the overall timing of things. I’m not so clear how using a coefficient ( as in time(.1 * speed) is different other than introducing a variable (which, for instance, could be controlled by a “speed” potentiometer). Aren’t time(.1) and time(.1 * speed) basically the same, except for the latter is a changeable argument due to the variable “speed”? The both are applied globally, aren’t they? Am I understanding this correctly?
The idea of hysteresis is beyond my working knowledge at this point. As I get in there and start playing with the timing, I’ll want to come back to that. But it is good to know there are strategies to deal with potential timing glitches.
There could be multiple instances of time() throughout the code with different speeds, if you want to change the relative speed of the whole thing, you’d have to update each call to time(). Thats where a single variable as a coefficient can come in handy.
The easiest way to implement some basic hysteresis is to remember a value, and not change it unless the difference is larger than some threshold. For example:
var value
export function beforeRender(delta) {
if (abs(readAdc() - value) > .01) {
value = readAdc();
}
}
In the above code, the value variable won’t change until its more than 0.01 different. That way some noise under that threshold won’t cause value to change. So for example, if value = 0.5, a reading of < 0.49 or > 0.51 is needed to get a new value. Experiment with the threshold to get a value that is small enough that you still get good control responsiveness, but one that is higher than the noise/jitter.
You can export the var to see it in the var watcher. e.g.
