I kept thinking of patterns as "programs" but

1

I kept trying to think through the pattern code as if it was a self-contained program all on its own. Like I used to write in my Fortran class in 1993. That may be true in some ways but I think it’s the wrong perspective.

Do I understand this correctly, that the pixel Blaze is basically running through the code over and over automatically through the index count for each frame?, and we are just inserting code to manipulate what gets rendered during those Cycles?

I kept seeing statements in the Forum like “the render function gets called for each pixel” and I kept thinking what code is calling the render function?.. Now I realize that part is built in and not part of the code. Talk about backing up to square one LOL

2

The analogy I’ve been using is a two stroke engine.

PB, assuming you’ve either given it a map, or at minimum told it how many pixels you have, does two things over and over, and a few just once.

  1. (once) it initializes things for a given pattern loaded

  2. it runs pre_render things, if any function exists for that.

  3. it runs render things, using the render best suited (so 1D, 2D, 3D)

  4. go back to 2

Technically if the pattern has sliders/etc, there is a step in there for that stuff so it can update. Think of that as part of the pre_render for simplicity.

1 Like
3

I think we both share that Fortran mindset “problem”, though I pre-date your experience by, well, a good long while… do loops, nested do-loops and calls to subroutines and all…
But @SeaLaVie , I really like your description PB Code, I think the key term is render (Index)

Seems pretty two-strokey @Scruffynerf , and its an apt description, but there can be a lot of nice parts in there. It seems a two-stoke with dwell in the pre-combustion (pre-render) phase, I think. Lots of timing things and compound use of waveforms… kind of Fourier-like. That’s where the good stuff happens. I think. And if this makes no sense, well just ignore the babble.

1 Like
4

The reason I use the engine analogy is that timing matters: you can’t do too much (like lots of calculations) in one of the phases or the engine stutters and framerate drops or it’ll time out.

1 Like