Ok, so as an example of how to change code, here’s KITT, done so it will work on your dodeca
and look good:
leader = 0
direction = 1
// pixels = array(pixelCount)
limitedPixels = 20
pixels = array(limitedPixels)
// speed = pixelCount / 800
speed = limitedPixels / 800 // you might want to adjust this value to taste, or make a slider
fade = .0007
export function beforeRender(delta) {
leader += direction * delta * speed
// if (leader >= pixelCount) {
if (leader >= limitedPixels) {
direction = -direction
// leader = pixelCount -1
leader = limitedPixels-1
}
if (leader < 0) {
direction = -direction
leader = 0
}
pixels[floor(leader)] = 1
// for (i = 0; i < pixelCount; i++) {
for (i = 0; i < limitedPixels; i++) {
pixels[i] -= delta * fade
pixels[i] = max(0, pixels[i])
}
}
export function render(index) {
// v = pixels[index]
// here's the new magic... using the mod function aka %
// (which will show the remainder of a value divided...)
// so pixel index 20 will match pixel 0, pixel 21 will match pixel 1, 41 will match pixel 1, etc
v = pixels[index % limitedPixels]
v = v*v*v
hsv(0, 1, v)
}
Please let me know if this works for you (it should do a red ‘scan’ on every bar, back and forth)
and if it’s clear how you could (if you wished) modify other patterns similarly.
KITT is good, because Ben’s video walks you thru it:
hey @wizard, is changing pixelCount possible or a bad thing? I didn’t do that out of concern it might break something, but it would make it easier if just setting pixelCount = 20 could be done at the top…
render(index) iterates thru all values, but does it depend on pixelCount?
PixelCount comes from the settings page - you can modify it in code but it will get overwritten the next animation frame and is’t going to change how data is sent to LEDs, only how that variable is used in your pattern. If that is what you want, you have the right approach using another variable (limitedPixels in your example).
Just to follow up here, and I’ll be posting more once I actually get this built, so I can document it all then…
I considered using those nifty new “forkable” LEDs to do an infinity dodeca, but as discussed above, you need to do nine forks (and solder those strands into the main strand) to cover all of the edges. I was trying to avoid that if possible (since I’d have to solder, reprotect from electrical conduction, etc etc )
You can do a continuous wire for the 20 vertexes (Google Hamiltonian path), but to cover all 30 edges, that’s the Euler path (or lack thereof) and there are too many odd vertexes (more than 2). But I was pondering this last night and realized that I didn’t have to run all of the LEDs at once (the joys of fairy light wiring) , and it turns out, if you consider doubling the paths (so you can run all paths twice, as in do some LEDs and then do the other LEDs the second time thru), that doubles all of the vertex connections (making them all go from 3 (odd) to 6 (even). So I can do one long run (20 leds on 20 vertexes, then cover 30 edges with 180 LEDs (6 per edge), so long as I do it in two (or more, 4/6) passes… bingo, 200 LED strand all used, no breaks needed. It won’t be in a nice orderly manner, it’ll jump around, but that’s irrelevant for 2d/3d maps. Anyway… More once it’s built.
Very interesting approach and I can’t wait to see the visual data pathing to better understand. I still want to tackle another Dodec with correct strip pathing for 3D mapping. But I’m still harvesting my pineapple!
Wow, just WOW, these are some seriously awesome projects guys! And I’m stoked you’re down to share the designs etc! I’ve been wanting to make my own CARL ever since seeing the deeplight guys in action!