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.

@weightless i changed the opening mechanism a little, now it works. a strange behaviour is that the borders of the open and save message stayed bold after opening or saving a file. for open i solved it with a short delay, for save it doesnt work so far. if using a bang button instead of a message it works like usual. ps.: very nice random possibilities conway 1.22b.zip

another game of life sequencing attempt: conway 1.22c.zip

here is a nice collection of game of life objects, perhaps the 3d objects are useful for mapping several sounds or other parameters: https://commons.wikimedia.org/wiki/Game_of_Life?uselang=de and here are some examples of existing musical implementations:
http://people.ece.cornell.edu/land/courses/ece5760/FinalProjects/f2011/lba36_wl336/lba36_wl336/index.html
http://tones.wolfram.com/generate/GLVpE3LbDUTbzs1eNYPVjqdtPYK299o6uu1CFDvWhhGSQ7VAfC
http://grantmuller.com/projects/game-of-life/

Here is a new version of the patch with some fixes, including the open fix by @Jona. Now the response from the messages is faster and they all work properly. Also now the "add", "remove" and "swap" messages retrive the state from the data structure rather than from the last state list. What happened before was that if you for example clicked on "add" and then "swap" consecutively before iterating, the "swap" would affect the state prior to the "add" modification.

The idea behind the various random possibilities is to be able to provide some changes automatically when the system gets stuck, for example by shuffling, adding or removing some cells after the output number of live cells hasn't changed for, say, 10 generations, or something like this. I think that this, together with the more general randomisation option, should help in getting past what seems to be the main disadvantage of this particular rule set, which is that it's rather unpredictable to know how many generations it will last before it settles into a static configuration (or into emptiness).

conway2.0.zip

@Jona Thanks for the links, I think some of the shapes in the first link refer to a slightly different variation of the rule set. That of course could be implemented as well I think, as well as other rule sets for 2d automata beyond the game of life, but that might be another patch altogether. I like what you're doing with the patch by the way

@weightless nice, everything seems to work now. one little graphical error when i open or save something is that the message borders stay bold until i use it the next time. for open i solved it with the short del, for save i didnt found a solution other than accept it or use a bang button instead. perhaps its a windows specific problem, at least it doesnt influence the functionality:

i also made a little (subjective) performance test: 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.

@Jona I see now what the delay was for, since the logic didn't really required it. That's odd, would be interesting to know what exactly causes it. I don't get that on mac by the way.

i tried to create a second voice (a third color). everytime a living cell leaves a field it creates a third color on that field if there is no new living cell. the third color is deleted directly after it is played. @weightless theres also a suggestion how to change the grid size in the help patch. i am not sure if it makes sense... conway 2.0b_test.zip

i implemented a third voice + a scale change from @weightless. the concept of the third voice is that the second voice gets transformed to the third voice after it is played. if the third voice is not deleted by new living cells the third voice disappears after it is played. (the voices send only midi values at the moment, its without soundsynthesis...) : conway_2.0e_test.zip

conway_2.0e3_test.zip @weightless now there is a switch for the voices. the mechanism is at the bottom of the guts and the seq subpatch. it works only for the stepsequencer like it should, because the stepsequencer changes the notes. for iterating and playing the whole grid every step, i think every square needs to be updated for the second and third voice. i dont know if that would be too inefficient. now its also possible to change the color of the squares with the second or third voice and the highlighted color with a mouse click. at the moment the click just changes to dark blue if its not dark blue already, you could also switch between the 4 different colors or something else. but perhaps its good to keep it simple.

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.