Hi everyone,

I'm aware that this has been attempted before but here's my take on implementing Conway's Game of Life using data structures. It's resizable and has outlets for values which I think are meaningful. The initial state is set by clicking some cells, and new cells can be added or removed at any time and will be included in the calculation for the next generation. It works with Pd 0.47.1 vanilla although it uses some abstractions from list-abs.

One hiccup with this implementation is that the bigger the gird the slower it is at updating the cells, so much so that for some big size/high speed combinations it's very sluggish indeed and borderline unusable, despite cpu levels being close to zero. I suspect this is due to the constant update of lots of scalars, but I have no experience with this.

UPDATE: the latest working patch v2.0 is a few posts down

A big thanks to @Jona who's helped me developing this, as well as everybody else who's given me advice on the topic. I've got to say that for a first project with data structures I definitely could've gone for something simpler, but I'm happy with the way it's turned out and I've learnt a lot.

@Hugo-Legrand I think I agree with you. Actually, directly mapping the crude grid to some pitches, I don't think that works very well in concept (@Jona came up with some nice examples, but the most interesting ones used 2 or 3 "layers").
Because of the way this cellular automata works, cells tend to reproduce according to the state of neighbours, and therefore there tend to be clusters of cells very close to each other, which musically doesn't make so much sense to me. Like you said, probably more interesting results could be obtained by processing the output data differently, I don't know.

The point is: the idea behind this patch was to create a 2d cellular automata, period. Everything else comes later (ie, the interpretation of the output). Of course, the faster the automata can run the better, which is why I would say that if we can get faster results with ophelia it's worth a thought (especially considering that updating/widening the scope of this patch as it is now is fairly tricky and requires more than a few headaches.. for me, anyway). But if you can get some use out of this patch, and the update speed doesn't hinder your projects, than that's great!

Regardless, I will upload the patch with those new 22 rules shortly.

Ok. I've worked on it today, I can know recall shapes on a grid of any size.
Also, another thing that would be awsome, the possibility to "clic" the shape on the grid. And being able to apply a rotation, and a symetry.

I'll post it when it's done so @weightless you can properly integrate it into the patch.

Rules involving more than two state is something I can't stop think about. Maybe I'll give it a try. If I have 2 months to kill.

Here is the 2.1 patch with the 22 different rules. I haven't done any of the cleanup I intended but it's still fairly tidy I think (with changes inside pd guts > pd calculate new states > pd rules).

life2.1.zip

@Hugo-Legrand that sounds interesting, looking forward to seeing the patch.
I came across this, which looks like a neat idea, except that it would be even nicer to be able to store those shapes as well.

I'm wondering if the text object does not the cause this extensive usage of cpu?
What do you think?

@Hugo-Legrand I suppose it's possible, but I have no way of knowing whether the text objects are "heavy". I guess the only way of knowing is to modify the patch to use lists in place of text, but that might prove more than a little tricky, especially for calculating the neighbouring cells in variable-size grids. Besides, I wonder if there would be a clear advantage in cpu load. My feeling is that graphically updating the data structure cells is slow, which is why when the iterations are very fast, not all cells have always time to update but the text never skips. For example, with a simple runner at [metro 4], the cells don't graphically update fast enough, but the cell count is always 5.

If somebody knows whether the [text] objects are cpu intensive that would be very interesting to know.

@weightless [text] is considerably slower than [list] and [array], but in this case i am pretty sure that the data structures are the culprit. The way data structures are visualized is extremely inefficient, which is the reason that the use cases for data structures are limited. i think ofelia is the future of interfaces in Pd.

@ingox That is good to know! But I agree, especially in this case in which there is not so much text to write/retrieve. I also happen to think that data structures are too limited, inefficient and clumsy to program. I did install ofelia and had a quick look at it, and it definitely seems like the way to go. A bit sad that it's yet another thing to learn from scratch right after I was starting to get the grip on data structures, but it looks truly promising to finally being able to program decent interactive interfaces.

If we can get ride of the "last.state" text objects , and keep the list
as it, without even cuting it in rows, until it's absolutly necessary, maybe it can get faster.

Edit: It did not work. Pure data hates long lists !

Also, a switch to turn the Data structure display off would be justified, since we are generating control data for audio synthesis and sequencing

This might be a very ignorant question, but why not just use toggles for this project? You can easily set them up so that clicking on them changes the colour, which should give more or less the same effect as what you've achieved through data structures.

@LiamG not ignorant at all i think you are right, you can achieve the same result with toggles and dynamic patching. i think we even started to patch with the toggle method before discovering data structures. i think data structures are still a little bit more efficient than toggles, but maybe i am wrong. they store the graphical and the visual representation at once and they can work like an array and each field is one element of the array. perhaps they are also more efficient because they carry less information, its only a pixel at a position with a color. we were exploring data structures at that time and the graphical side of the patch is roughly based on https://forum.pdpatchrepo.info/topic/10734/vanilla-struct-sequencer that lead to https://forum.pdpatchrepo.info/topic/11012/grid-multi-pattern-step-sequencer-abstraction so we already had a visual grid to base the patch on.

That's right, as far as I'm concerned this patch and the sequencer were experiments to see whether some basic graphic interfaces could be done with data structures (and believe it or not, one of the reasons for that was so you don't have to make a toggle-based sequencer every time you need one). Turns out they can, but they don't seem to be very efficient and are rather clumsy to program and with major limitations. Going forward with making these kind of interactive objects, now that there's ofelia available, I think it's kind of a no-brainer, especially for someone who has to learn either from scratch. If I'll have more time to work on the patch I will definitely consider redoing it with ofelia.

@Jona do you find that your ofelia experiments and patches run faster than data structures?

@weightless i only implemented the multislider as a more complex interface element so far, but i would definitely say yes, they are much faster because the lissajous figures are quite complex and run very smooth. of course, like data structures, they need some extra work.

@Jona Sounds great, and a lot more flexible than data structures as well. The only thing is that at first glance it doesn't look so easy to learn but perhaps I'm wrong. When I have some time I'll try it out.

Hello. It's been a few days. Finnaly I could implement the drawing space.
So that's it, we can know separatly draw shapes, then add them by clicking where desired on the grid.

First, select a rule. Then start the metro. Now you can draw.

life3.0.zip

@Hugo-Legrand Thats very nice, also that its now posibble to change the rules on the fly or sequence them. Is it that it draws the first iteration of the left pattern into the right screen? and how big is the left drawing area?

Here is a little video that shows what you can do:

@Hugo-Legrand thanks for the video, very nice. somehow it didnt work like that for me, perhaps because i had to find a library for count and creb is the wrong one? that was the only missing object. or it replaced another object with something from a different library?

count.zip

Here it is. An abstraction from the Pd-extended.43 era.

@Hugo-Legrand thanks, thats from the creb library. and i need to start the metro first