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 Nice! i think you can double the efficiency by working directly on the colors instead of the state (getting rid of the redundant state information altogether).

Also there are a few methods to prevent the cells to be altered in size by dragging the corners: You could implement a safeguard that resets the size on change. But it is more elegant to use fixed sized polygons with static values instead of cellsize and than let the gop range scale them to the actual desired size. i can get into this in more detail later if you are interested, don't have the time for it right now...

@ingox Excellent idea, thanks. I got rid of the state field but it doesn't improve efficiency much as far as the drawing lag is concerned. Maybe one trick worth exploring is to only graphically update those cells whose color have changed from the previous generation.

Actually I got the gop stuff working by trial and error and I don't really know what's going on, If you could take the time to explain how it works in more detail when you can, it would be very much appreciated. Thanks a lot.

That seemed to do the trick, only updating the cells whose state has changed allows to go much higher in speed and grid size.

conway1.1.zip

my first attempts to map the game of life cells to midi pitch values conway_1.1b_midi.zip :

another idea is to play the pattern from left to right or bottom to top (or the other way around) and perhaps to iterate it only every first step. i will also think about different musical implementations.

@weightless Maybe i promised to much.

This works: conway1.1b.zip
i added a select after the struct in [pd $0-cell]. It now only changes the color on click. On change it resets the cellsize.

This works, but with a bug: conway1.1c.zip
Here the filledpolygons have a fixed size of one pixel and the range is set only to height and width values. If you have a 10 x 10 grid with cellsize 15, the size of the gop is set to 150 x 150. But the range is now only 10 x 10, so the 1 pixel filledpolygons will be stretched to 15 x 15 pixel each and will still fill the whole gop. i changed the bordersize to 2, so it will look the same, but the reason that this is necessary is also the reason for the bug: The 1 pixel polygons share borders with their neighbors, or to say they overlap, so it is possible to click two or even four polygons at once.

So the second method maybe not possible here, the fist one should be alright.

In both versions i added [dirty 0( after the donecanvasdialog messages. This prevents Pd from asking the user if she wants to save the patch on closing, which is the usual behavior after donecanvasdialog changes the patch. This also hides the indication that the patch is altered and won't ask if you want to save on close if you alter the patch manually and than [dirty 0( is send, so caution is needed while developing with this!

@ingox i like 1.1b. now its even faster. when it iterates a 16x16 grid every 20ms i have cpuload of approx. 20% edit: seems it was my imagination with the better performance. nevertheless, i think its very smooth since v1.1.

@Jona i only changed the things i mentioned in the post, nothing about the performance...

@ingox my mistake, still very good changes

@ingox Thanks for your suggestions, I've implemented your mods from 1.1b. I didn't know that struct outputs other messages than click. I think I understand the thing with gop scaling, basically instead of scaling the cells, they just get bigger and then get resized only graphically by the gop. that's clever, but unfortunate that you need to have the 1 pixel overlap. Good to know about dirty 0 as well.

I'm trying to implement other messages for loading and saving seeds as well as introducing various kinds of randomness, but I think I've messed up the patch, and also realised there are some redundancies and things that don't make sense. I will post the updated version once I can get my head together to fix it.

@weightless very nice abstraction. looking forward for the update

Here is an update with a bunch of new messages for randomisation. More explanation in the help file. The open function doesn't work but I can't figure out why, might be something trivial but I probably got enough of this thing for a while. If anyone has any idea how to fix it that would be great.

conway1.22.zip

EDIT: uploaded new zip with the missing abstractions

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