export function render(index) {
h = index/pixelCount + time(.1)
hsv(h, 1, 1)
}
Is the following true:
The value for h is 0/149 to 149/149, incremented by 1/149 for each loop when pixelCount is 150 ?
The index increments by 1 for each loop and the time interval between increments is 6.5s/150 ?
No numeric value is actually added to h with each loop for the expression " + time(.1) " ?
Pretty close! Index goes from 0 to 149, with only a number of nanoseconds between each consecutive call. Thus, index/pixelCount goes from 0/150 to 149/150.
time() always outputs a fixed point number between 0 and 1. In this example, it takes 6.55 seconds to loop. Since a pattern like this probably runs at about 400FPS, all 150 calls to render() happen within 3ms, so time(0.1) is changing very slowly compared to how fast index is advancing.
Now we can think about h, which will always have a value between 0 and 2. However, in any calculation of a whole frame, the entire range of h values will end up spanning an interval of length ~1, but with a starting offset coming from time(0.1) that progresses slowly.
Values in 0…2 are fine to feed to hsv() because it wraps inputs outside of the interval 0…1. Calling hsv(1.05,1,1) is setting the same color as hsv(0.05,1,1). When the length of the strip is given hues from 0.33 to 1.33, it’s a rainbow around the hue wheel that starts with green and ends with green. A little later it’s 0.5 to 1.5: cyan to cyan.
Quick clarification on a minor detail. time()'s timebase is snapshotted for each animation frame. So a call to time() in beforeRender() is the same as a call to time() in render() even for a lot of pixels or really slow code.
This way an animation frame doesn’t have any skew or “tearing” that might otherwise occur, for example if you use time() to draw a threshold where the difference would be more noticeable than a smooth gradient. I think of it more as an animation time base than a measurement of real time.