Got the linear texture scaling working and fell in love with the ColorFromPalette function.
http://www.youtube.com/watch?v=82luIFpSDgA
Looking good!
This is where I think the next batch of my own projects are going to be headed: total separation of “generate the animation pattern” from “choose colors” from “render it onto some LEDs”. More or less, anyway.
Using palettes is fun, right?
Indeed @Mark_Kriegsman , sorry for ignoring your paletts so long.
The seperation of animation/colorset/mapping makes totally sense and with that it is easy to adapt an effect for some leds in a bottle or a for thousands of them in a room or on a stage. A really good approach!
I’m curious to see how you wind up including it in your work… you’re on a roll!
And I would add a 4th field: the complete seperation from all timing stuff so that it is easy to switch program-wide between scripts, oscillators, random values, soundreactive behaviour, external event triggered changes, …
Yes! Having “external” time base!
I’m mostly using ms as a time base, with the simplest source being “millis()”. If you want it twice as fast, use millis() * 2, etc. but it also lets you stop time, reverse it, or yoke it to oscillators or external triggers.
So: yes!
The possibility to run periodic animations with a fine adjustable speed forward/backward is a powerful thing for synchronizing them to music. So we need for the rotating palettes also a color loop direction.
ihue = (timebase >> 8) & 0xFF;
Done!
Very nice, Stefan! I’ve started separating them as well, with the addition of effects (dim, spiral, stream, etc) being separated from the pattern and palette. It provides a lot more variety.
Looking foreward, when we have the same hardware and can start to develope stuff together, @Jason_Coon .
@Mark_Kriegsman Would you mind elaborating on the code snippet: ihue = (timebase >> 8) & 0xFF; I don’t understand the ‘&’ in relation to the hex.
It’s a bitwise AND operator.
http://arduino.cc/en/Reference/BitwiseAnd
If X is an unsigned integer of some type, then this:
x & 0xFF
is basically the same as this:
x % 256
except that the bitmask is about 400 times faster than the modulo operator in this case.
Another way to write what I wrote would be:
ihue = (timebase / 256) % 256;
First, I’m slowing the timebase down (dividing it) by 256, so that instead of (presumably) milliseconds, it’s roughly quarter-seconds. Then I’m doing “mod 256” so that it counts up from 0…255 and then starts again.
In this case, 256 quarterish-seconds is roughly 64 seconds, or approximately one minute.
I’ve basically make a counter that loops from 0…255 over and over again, roughly once a minute, without the slow/expensive modulo/division operator.
And it’s relevant here, because if you speed up the passage of ‘timebase’, or slow it down, or reverse it, then “ihue” will also speed up or slow down or run in reverse.
@Stefan_Petrick I’d second this. I’m after patterns driven by external sensors, e.g. angle for a rotating 1D display. Having an arbitrary fourth field would be ideal.
Sorry for my bad english and limited understanding, but what means an “arbitrary fourth field”?
@Stefan_Petrick I mean that I’d like the setting of each LED in a pattern to depend upon the x-position of the LED, the y-position, the time, and a fourth value. That fourth value might be any sensor input, whether that’s music volume, or movement of the LEDs, or anything that we can think of.
Ah… the ubiquitous “void* context” !