nice project; i'd really like to see it, but there are some abstractions resp. externals missing in my program; e.g. the list-drip and others.

@noise list-drip is part of the list-abs library, they are not externals but abstractions made with vanilla objects. You can install the library from pd > help > find externals menu, or get them here https://sourceforge.net/projects/pure-data/files/libraries/list-abs/

Hello, I'm very impressed.

Here is a little addition I've made to the patch:
The possibility to add arbitrary shapes to the current state.
This allows you to "play" the game.

In this patch, you can't resize the
grid, but I will fix that.

conway2.0 2.zip

@Hugo-Legrand thanks, thats a great idea the limitation was the data structure gui, so i was already thinking about porting the gui to ofelia

Ok. What would it change? I don't know ofelia.

@Hugo-Legrand that was my finding back then "with a maximum of 512 squares iterated every 50ms it runs really smooth. with 1024 and the same iteration time it needs approx. 4 times the cpuload and it isnt smooth anymore, while iterated every 200ms its still good. so there are (of course) limits depending on the grid size, the metro, the computer and the number of living cells. i thought with a bigger grid it could be useful to make the graphical representation invisible, but its only a small difference in cpuload. nevertheless, i think its totally okay to live with those limits."
i thought the limitation was mainly because of the visual data structures, but perhaps thats not true. but if the pure data gui is the limitation, then you could make much bigger/faster grids. perhaps @weightless knows more about the limitations? ofelia is a gem like external from @cuinjune

Ok. I didn't understood because, when I said the grid can't be resized, I meant , because, in my patch, the shapes are stored for a specific grid. And I'm gonna change that.

Yes the cpu load is a big issue. And I agree, PD gui could be an important factor.
It could be justified to create a C object. An osc link to Golly is doable, since it handles Python scripting.

Ofelia seems very interesting.

@Hugo-Legrand hi, thanks for the interest in the patch. I made it a few months ago when I had a lot of time for it, I've been meaning to keep developing it but never have, so when I will have time I'll work on it more.

I did make a new version with the 22 rules shown here, so more than just Conway's game of life, but I want to clean the patch first and also I think some things can be optimised for Pd 0.48, in particular with list store.

Your idea of inserting "shapes" is very interesting and definitely worth implementing (as a matter of fact, my idea to interact via "add" and "randomise" messages tried to do something similar, although that was intended for automatically triggering the messages when the system gets stuck because you never have enough time to "draw" new shapes in between generations). One thing that comes to mind straight away is the ability to have a graphic representation of those shapes as well, so perhaps a second grid on the side which shows the stored shapes when you scroll them, and allows you to draw/save new ones.

@Jona Hi, The problem with sluggishness, as far as I can remember, was that in the first version of the patch all cells were updated at each generation. In the last version 2.0 only the cells whose state has changed are updated, which is much more efficient. Of course, the bottleneck is the fact that updating lots of data structure cells very quickly is not smooth, so with bigger size grids (or when there are lots of cells at play) the same problem occurs. I think this might be a limit of working with data structures, but I wouldn't know for certain.

The other thread about your work with ophelia seems very interesting indeed, and perhaps that is the way to go for these kind of patches if they run smoother? I haven't tried it yet myself, but it's worth considering before putting a lot of work into this patch again if it'll never run very smoothly.

One my 2009 2,26 GHz Intel Core 2 Duo macbook pro,
If I run the computation of a 16x16 grid every 20 ms , it uses 30% of the cpu. Seems a lot, but I seriously doubt I'll ever need to run it at that frequency.
With a 30*30 grid, with 1 second interval, I have a cpu load under 10%.
This allows to make a computation every beat at 60 bpm, every 2 beats at 120, and every 4 beats à 240. So it could be used to generate patterns live for ambient, minimal and speedcore.

The computation could be triggered even less often if every bit of information generated is used in a more creative way, to generate longer, complex soundshapes.

No it will be useful. even with some limitations. Let's focus on what works !
And those new rules could be very useful.

@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.