# Glacial Speed - slowing it all down

**URL:** <https://forum.electromage.com/t/glacial-speed-slowing-it-all-down/120>\
**Category:** Ideas and Tips\
**Created:** [November 18, 2019, 6:42pm UTC](https://forum.electromage.com/t/glacial-speed-slowing-it-all-down/120 "2019-11-18T18:42:54Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Booli](https://forum.electromage.com/user_avatar/forum.electromage.com/booli/32/1568_2.png) [@Booli](https://forum.electromage.com/u/Booli)\
**Post date:** [November 18, 2019, 6:42pm UTC](https://forum.electromage.com/t/glacial-speed-slowing-it-all-down/120/1 "2019-11-18T18:42:54Z")

</div>

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?

![image](https://forum.electromage.com/uploads/default/original/1X/fb2b25dd24aac8ee80c7154dc6067f2f0203d5d9.jpeg)

---

<div class="post-metadata">

**Author:** ![alandoak](https://forum.electromage.com/user_avatar/forum.electromage.com/alandoak/32/80_2.png) [@alandoak](https://forum.electromage.com/u/alandoak)\
**Post date:** [November 18, 2019, 9:55pm UTC](https://forum.electromage.com/t/glacial-speed-slowing-it-all-down/120/2 "2019-11-18T21:55:00Z")

</div>

> [@Booli](#):
>
> u are asking

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.

---

<div class="post-metadata">

**Author:** ![wizard](https://forum.electromage.com/user_avatar/forum.electromage.com/wizard/32/4_2.png) [@wizard](https://forum.electromage.com/u/wizard)\
**Post date:** [November 19, 2019, 3:33am UTC](https://forum.electromage.com/t/glacial-speed-slowing-it-all-down/120/3 "2019-11-19T03:33:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Booli](https://forum.electromage.com/user_avatar/forum.electromage.com/booli/32/1568_2.png) [@Booli](https://forum.electromage.com/u/Booli)\
**Post date:** [November 20, 2019, 8:32pm UTC](https://forum.electromage.com/t/glacial-speed-slowing-it-all-down/120/4 "2019-11-20T20:32:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![wizard](https://forum.electromage.com/user_avatar/forum.electromage.com/wizard/32/4_2.png) [@wizard](https://forum.electromage.com/u/wizard)\
**Post date:** [November 21, 2019, 9:16pm UTC](https://forum.electromage.com/t/glacial-speed-slowing-it-all-down/120/5 "2019-11-21T21:16:25Z")

</div>

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:

```auto
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.

```auto
export var value;

```

Then click “Enable” on the Var Watch panel.