As they say in the Hitchhikers Guide to the Galaxy… “Don’t PANIC!”
I’m making progress. I am on my third rewrite 
and have gone thru a few more examples.
exporting variables and enabling variable watching is a really splendid idea
2 Likes
Eureka!!! “Lightbulb moment!!!” 
Just need to get the random delay working. I keep getting “Execution steps exhausted” does that mean I am looping too fast? I tried to make a delay using
while (time(0.015) < 0.9) {
}
and it blows up with that error. My idea from you peeps is to use a wave function with a certain period… waves got from 0 … 1 so if I keep checking for my value being less than 0.9 I would think that would be good… but I may be checking too fast…
Rather then a while, let’s look at the “engine cycle”
BeforeRender intentionally tracks the delta of how long since the last BeforeRender… Why?
Because we don’t know exactly how long Rendering will take. It could be a split second, it could be longer. Depends on how long it takes to calculate all of those pixels. We’re only lighting one pixel, But it still has to look thru all of the pixels. [This is why adding a huge amount of pixels slows down frame rates. Even if you only light up one pixel.]
Figure out a way to use that delta.
Your error is because that “while” is running out of available execution time, and the “engine” is stalling due to that pause.
1 Like
Btw, using a time() function is another good way to track a timed change, it’s the while that got you into trouble. Try an If… Depends on length of your loop, and how precise you need the timing, of course. But if you check value of the time and it’s near zero, or maybe less than the last time you looked at it (see how that works?), then you know it’s a new cycle.
So I decided to ponder this over night. I couldn’t see how to simulate a delay using time with only an if statement. I kept coming back to needing some kind of looping while, for, do, or something… but then I got to thinking about the functions that @wizard gave us in the PB… being the beforeRender and render… One could use the function beforeRender itself as a type of looping device as that is what it is doing. Then using an if statement to see if the time wave had gone far enough if not then just exit out of beforeRender… Then I think I had another “lightbulb moment” after reading @Scruffynerf’s hint above … beforeRender has a delta that is the amount of TIME (delta) since the last time it was called. So if you had a global variable delay you could keep adding the delta’s and check to see if enough time has elapsed… if not drop out of the beforeRender and render again… While this exercise is taking me MUCH longer than I expected, I have learned a bunch and had fun. I can’t wait to see share what I did and see how other’s accomplished it as well.
1 Like
Yes! But is your pixel twinkling?
1 Like
OMG always triple read the requirements… I am so out of practice. I am indeed only worrying about fading out not twinkling. hmmm well so muh for rev 4 being the one. Rev 5+ here I come! 
Luckily it is working as I expect now so modifications are a little easier… before I had what best could be described at random static and was clueless for the longest time about why… lol
Hey @devoh, when it comes to the different ways to track time and delays, I thought you might find this interesting – search the forum for the word “accum”:
https://forum.electromage.com/search?q=accum
And for what it’s worth - your whole thing about getting “execution steps exhausted” while trying to make a delay is exactly the first issue I emailed Wizard about a little over a year ago, and shortly after that I was hooked.
3 Likes
Some of us should golf this! We could go for minimum Logical Lines of Code, or [edited based on experience] maximum FPS @ 1000 pixelCount (for a given HW v2 or v3, and “no LEDs” setting).
I’ve got a minimal version going, an aesthetic version, and one that’s readable
1 Like
I think a golfing section for advanced users sounds like a great idea!
For those who haven’t heard the term:
In golf, less strokes (hits of the ball) the better.
Golfing code, reducing the number of characters/size of the code to the minimal needed to do the task.
For the old folks in the room, “I can name that tune in 5 notes” “4 notes…”
Lacking (yet) a controller I’m gonna wing it , ask stupid questions.
I get the need for “dwell time”, for sure. Reminds me of the fascinating talk I attended given by the developers of Windmap… https://earth.nullschool.net/ Dwell was absolutely their key to superb visualization. I hope this point is not lost on me.
For your second point, I’m not sure what is meant here by using “a single value” to potentially control a bunch of LEDs but I guess that’s the point… figure it out. a good challenge it seems!
1 Like
Since we’re getting later in the week and you don’t have a board yet, @JustPete, I thought I’d add some commentary to Zranger1’s:
The alternative requires the storage of only a single value, no matter how many pixels you may eventually want to light.
I interpreted this as an invitation to think about how to generate multiple random values that can persist for the many cycles of render(), but without needing a lot of memory (such as an array, or pointer into it). The challenge seems to call for picking a random color, random LED, random duration, perhaps random twinkling, and random interval between each LED. We could store 5 variable for these random values from random() as well as some timers, but his point is that this scales linearly if we ever want to set random colors for 5000 LEDs.
Procedural generative art holds some clues, as does the PRNG wikipedia page and the “Static random colors” pattern in the pattern library. A deterministic random number is generated from the random number that came before it (all the way back to the first, which is called the “seed”).
But if you’re new to PixelBlaze, you’ll learn a ton with the 5+2 variable approach to this problem!
2 Likes
In thinking about next week’s task, I’m likely going to build on this… That thinking to scale is important.
But I don’t want people to get lost in the weeds: designing for 5000 pixels can only happen when you understand how to design (and code) for 5 or 50…
Thanks. This is very helpful. And I really do like the background on how "randomness’ is generated and used here and elsewhere @jeff
I had figured the basic logic, just the syntax is new, along with definitions of terms.
For now, I am assuming/guessing that the +2 you refer to is WRT the BeforeRender/Render cycling. Perhaps.
Anyway, thanks for your kind replies.
This is great @Scruffynerf, if I find myself caught up. A board to work with will certainly help!
I, for one am keeping it simple here, one 50-pixel string. Then prepared to expand to a 16x16 array. That should be a good next step!
Maybe a decent teaser for this would be the variable names I chose for my “readable” version, which is my version that tries to not be clever.
export var hue, pixel, blinkDuration, offDuration, accumMs, twinkling, v
Clever is good! Made my best guess tho. and I’m sure the code has BR and R in it, right??!!
So starting tomorrow, Task #1 responses should be posted to this thread:
If you begin these Tasks after we’ve moved on to newer ones, please feel free to participate, ask questions (about the task) and post your code on the above thread. This is meant to be an ongoing learning environment.
Task #2 will be posted at some point tonight or tomorrow. I’ve got a fun one coming.
So, I’m a bit bogged down here… awesome as it all is and will be.
Consequently even this task of selecting a bunch of pixels then lighting another bunch doesn’t seem so trivial at this point. So, if anyone has a moment, could you provide code for just this task,? real simple like? 
Thanks if you can!
I highly recommend looking at the patterns on patterns.electromage.com
Open them, read them. Some are really well commented, some not so much.
Having working examples, and there are many, is a good way to see code in action.
I’ll try and put together a “light a bunch of pixels” code in the morning.
1 Like