I realize it’s not meant for nor optimized for POV, but I just had to try. Running the Noise example with the following params:
kMatrixWidth = 24;
kMatrixHeight = 2;
kMatrixSerpentineLayout = true;
scale = 25;
speed: the one with the visible wedges has a speed of 100, the other is set to 50.
Interesting to say the least … I’m not seeing a whole lot of red. I see the occasional magenta (on another strip that’s sitting at my desk), but no reds.
Known issue, soon to be fixed; getting the ‘ranges’ for all the noise to come out full width and centered had been a PITA, but I think Dan’s got it now. (The output range for ‘hue’ was skewing too high.)
Glad you’re playing with it! This stuff is awfully fun (once we get the core bugs under control). Performance on AVR is good; performance on ARM looks great…
I love the first pic, it looks quite different compared to all the other POI I have seen on the net.
Will be much better as well when there are some more colours in there.
@Mark_Kriegsman , I figured it’s something you would already be aware of. This was running whatever bleeding edge code that was posted last night. One thing, can you explain the “wedges” on the faster speed one? Is that what it’s supposed to do?
So while I have expanded the range of values to cover all of 0-255 (or 65535 for the 16 bit version), it’s a bell(ish) curve centered around 128/32768.
For the 16 bit noise fill functions I do a transform so that while it’s still a curve,
It peaks at 0 and goes from there (important for things like summing up values for multiple octaves). I don’t believe I’ve don’t that yet for the 8bit fill functions - but either way - to get full coverage of the hue space I think you’ll need another shift/transformation on the hue values, first.
As for the color chunking you’re seeing - yeah, that’s expected for a high hue speed, because you’re basically leaping over more adjacent points/values between frames.
Cool, it’s that ‘leaping’ that I needed to know - it’s not the hardware, it’s the method in the software. 
It is a fun test though. And once you expand the range across all the functions, I can try it again.
note that this is still only using the Noise example. I haven’t touched the NoisePlayground yet … maybe tonight, if I have some time.
Ok - all the fill_raw_noise functions now follow similar rules for smearing across octaves and range of noise - which is they all re-scale the output of the noise functions from centering on 127/32767 to centering on 0. Note that for things using noise for hue, this will result in a shift from greens to reds.
Spreading/shifting the hue around more so that you regularly cover all possible hues is an exercise left to the reader
(Hey, we can’t do everything!
Also - you should play with noise playground, it does multi-octave noise, 16 bit noise, and has even more parameters to change up/play with.