I made a 64 output sequencer breakout box for @jjthrash’s Conway patch. I filed this under build help because jj said he didn’t find a lot of use for his Conway module, which in the version he passed me was rigged to a 64 LED box but had no outputs.
If you program in a “glider” formation and hook up the clock you get a type of “spaceship oscillator.”
The cellular formation of a “glider” can interact with other cellular automata to construct logic gates like AND, OR, and NOT. Therefore, it is possible to build a pattern of cellular automata that acts like a finite state machine using two counters. The formation that acts like a finite state machine has the same computation power as a universal Turing machine, also known as being Turing complete. This means that the Game of Life is as computationally powerful to any computer with unlimited memory and no time constraints.
So perhaps this can be classified as a programmable logic gate?
Here is the patch with the Breakout Box. You just have to input a pattern and hook up a clock.
use as a timbral control for some sort of additive synth (like the Chebyshev VCO that @biminiroad posted here)
use as a mulit-output gate or trigger, like in the video @futureaztec posted in a different thread
step sequencer for, say, a hi-hat type role that doesn’t carry the groove but adds flavor. Subdivide the main clock by 12 or 16 so that new patterns are generated every couple bars or so
Various thoughts:
if you want it to keep going indefinitely you have to use minimal still lifes or oscillators without using much else, which means you need to be able to use fairly sparse output
if you want it to go crazy (like starting with this form, which yields fun results over the course of a dozen or so cycles, you have to have a way to reset the form, which probably means a having a way to reprogram it. The trigger module appeared to have a random-reprogram, or possibly interesting preset reprogram gate.
it’s disproportionately CPU-intensive, but I haven’t taken a look at rectifying that. I think one source of CPU use is the interlace/deinterlace logic, which isn’t necessary if we expose the cell values directly on the patch
Getting this stuff sorted out really makes the difference. The logic “machine” for the game of life shouldn’t be CPU intensive. After all, arguably, it is not quite algorithmic. It functions more like a truth table that computes the outcome and treats this result as the next state space to be tabled for calculation. Calculation is a bit of a stretch though, because it seems to operate in the sphere of formal logic.
The optimization of this project is crucial to expanding it into a 128 grid. We want this field size because we want to accommodate a Garden of Eden.
As you can see from the table of records in the link above, the smallest arrangements recorded exceed the 64 grid, but are possible in a 128. To be clear, @jjthrash did post a 128 grid to accommodate this quantity of cells, but as he as recognized there are CPU limitations, so I am hesitant to invest too much effort with it, in the hope that things can be optimized at some point.
Why a Garden of Eden?
“A generation that cannot evolve from a previous generation by following the rules of Life is called a Garden of Eden. An orphan is a minimal subset of cells of a generation that has no predecessor. In other words, each generation that contains an orphan is a GoE.” (link)
It would be pretty cool to accommodate Gardens of Eden.
I just did a quick check with my 32x32 grid: I removed the interlace/deinterlace logic altogether, and the CPU usage was still up to 100% on my MBP.
The whole GoL patch is built around a single node, which represents a cell. If we can get the CPU usage of a single cell down, then hopefully that would make a huge difference. Otherwise I’m not sure what to do about it, since I don’t know precisely where most of the effort is being put.
I’ve built a 12x12 grid that is running at 20%. I’ve attached it. If you think it would be useful with a per-cell output, I can wire it up to do that if you’d like.
Really appreciate this. It passed the glider test and when I have some time later I will try out some complex combinations and see about rigging it up with some practical music ideas.
So I can run this on my iPad Mini 4. But it leaves no CPU room to do something with it patch wise. That’s fine, not a big deal, I can work on something on OSX and its still cool to have Game of Life standalone for iPad. However, having an optimized version of the 64 cell grid might be the best bet for the iPad in terms of music. I take it that the changes you made in the large version would produce something more efficient than the 64 cell posted above. If you have a chance to spit one out of your script I will post some strange emoji and a sentence of gratitude.
Wonderful. Feel free to share what “optimizing the gate signal” means. If it is a pain to explain, forget it. Also, what is the rough ETA on that change? Is it an Audulus 4 type timeline?
@Taylor and I have been talking about how inefficient it is to sample gate signals at audio rate and high bit rate. It would represent significant CPU savings to have a separate “digital” signal that is just 0 or 1 and only gets resampled when a change is noticed.
I’m not exactly sure how this would work in the backend, but I think the idea is for it to be as seamless as possible, where you could still attach a gate signal to a knob, for example, without having to translate the signals.
Or you could have something that generates gates in a complex way, but then the gate output is multiplied by an LFO, and at that LFO*Gate point, the signal just automatically turns into a normal “audio” signal.
The other thing that would help, especially for patches like this one, would be lowering sample rates for lights.
It’s a 10x10. It evolves for a while then you get some eddying formations (Blinkers, I believe – which are a type of oscillator). Marijn Heule gets the credit.
Input the pattern you see here into the grid in Audulus. Be careful when resizing not to accidentally illuminate the wrong button. When the Orphan has been inscribed into the grid, drag a wire from the clock to the input. conway144 - different clock.audulus (2.0 MB)
I am considering how it could function as an LFO. It could be interesting in the sense that you have a symmetrical initial state, that evolves into various patterns, but then stabilizes into a periodic event, thereby completing the series. I suppose one could also make a version with knobs so that the patch could be saved in its initial state…
