with the iteration patch from the ofelia doc folder as a starting point i made a little grid. its useless yet and i am sure it can be optimized, but slowly i get an idea from the lua language and open frameworks. quite a different way of using pure data
ofelia2_grid3.pd

@Jona Hi I'm sorry for the little delay. I fixed bugs including the one you posted on the github repo and uploaded on Deken. You will be able to find v2.0.4 shortly. Now your patch won't crash. I also added the "onset" parameter to Array getter and setter functions like you suggested. Please check out "examples/pd/misc" example. Thank you so much for your contributions to Ofelia. Please let me know whenever you find problems or have suggestions.

P.S: Raspberry Pi version is not yet uploaded to Deken. I will upload it tomorrow. (just in case RPi users read this today)

@Cuinjune thanks a lot for the update
inspired by the conway implementation from @weightless https://forum.pdpatchrepo.info/topic/10916/conway-s-game-of-life-implementation-with-data-structures i tried to implement the conway algorhithm. if you select the first preset and click the conway toggle you can see an example.
Ofelia2_GridXConway.pd
it works inside the grid, but i cant figure out the upper and lower border logic yet. i think it is a disadvantage of the one dimensional table for this case, perhaps a 2 dimensional table would make things easier? or i just dont get the logic it could be more difficult to implement the existing functions (like shift or shuffle) into the 2 dimensional table, that was quite easy with the one dimensional table. @weightless also used "2 dimensional arrays" (the [text] object) in his conway patch. something like this: https://github.com/syntruth/Lua-Grid sounds great for the grid logic, but still to complex for me to understand...

@Jona Cool work! I'm sorry I don't know much about the conway algorithm so I don't think I can help you. I may be able to help you if you simplify your question and post a patch that shows your problem.

@Cuinjune no problem and thanks, i think i can figure that out by myself. i will try.

These are the conway (game of life) rules:
For a space that is 'populated': Each cell with one or no neighbors dies, as if by solitude. Each cell with four or more neighbors dies, as if by overpopulation. Each cell with two or three neighbors survives.
For a space that is 'empty' or 'unpopulated' Each cell with three neighbors becomes populated.

and here i found a very basic example that is easy for me to understand, so i do not need the grid abstraction that i posted above (although it could be useful for further experiments):

function Evolve( cell )
    local m = #cell
    local cell2 = {}
    for i = 1, m do
        cell2[i] = {}
        for j = 1, m do
            cell2[i][j] = cell[i][j]
        end
    end
 
    for i = 1, m do
        for j = 1, m do
            local count
            if cell2[i][j] == 0 then count = 0 else count = -1 end
            for x = -1, 1 do
                for y = -1, 1 do
                    if i+x >= 1 and i+x <= m and j+y >= 1 and j+y <= m and cell2[i+x][j+y] == 1 then count = count + 1 end
                end
            end
            if count < 2 or count > 3 then cell[i][j] = 0 end
            if count == 3 then cell[i][j] = 1 end
        end
    end
 
    return cell
end    

https://rosettacode.org/wiki/Conway's_Game_of_Life#Lua

i still think that i need to use a 2 dimensional table like this for conway (like they did in the conway examples that i found too):

mt = {}          -- create the matrix
    for i=1,N do
      mt[i] = {}     -- create a new row
      for j=1,M do
        mt[i][j] = 0
      end
    end

@Cuinjune the conway implementation does work now (with and without borders). to achieve that i changed the 1-dimensional table into a 2-dimensional table. because of that i could not figure out yet how to make "shift" work again (except "shift up", which already works), but i will find a solution. the second issue is (again) saving the grid, because pd seems to crash when i return a 2-dimensional table (even without setting the pd [array]).
here is a minimal example of my issue: return_2dim_table.pd
i also wonder if it makes more sense to save a 2-dimensional lua table into a [text] object (which seems kind of an equivalent) or an [array] object. if i save into [array] i have to flatten the lua table before saving and "de"flatten before i load it back into the lua table. or get and set the array/table line by line. basically my main question is: what is the best way to save and recall a 2-dimensional lua table in pure data? everything else does work (and i think better than before).
i also put the matrix transformation functions (shift, invert and so on...) into single ofelia define objects (again), because i think it is better for keeping track of the code.
Ofelia2_GridXMatrix.pd
another issue that i found is that sending a bang into ofelia.bang does not work sometimes while a directly connected bang does work (the "Invert" bang in ofelia2_gridxmatrix.pd for example). which is not really a problem because there are easy workarounds, just wanted to mention it.
i really appreciate all the possibilities of the ofelia library, and i think i just scratched the surface....
edit: everything besides saving works again.

@Jona Hi, the video looks cool!

1. Sorry, I don't know what you mean by "how to make "shift" work again". I hope you'll find a solution.

2. Yes, returning a 2 dimensional table will cause a patch to crash since it doesn't know how to convert it to a pd list. Why do you need to return the table? If you're trying to write the table to a pd array, I think you can do it internally using a pd.Array() class without returning the table.

3. I'm not sure what would be the best way to save and recall a 2-dimensional lua table in pd. Even if you have a 2-dimensional table, you can write the data to 1 dimensional [array] and read back from it if your table has a fixed size. (e.g. 32x32 2-dimensional array can become 1024 1-dimensional array) And I don't know what you mean by flatten/deflatten the lua table.

4. I checked your patch and you are sending [invert( message into the "ofelia d -c11 -k $0-Invert" object which does not call ofelia.bang() function but ofelia.invert() function. So you should either send "bang" message to an object or rename the function to "ofelia.invert()"

Hi @Cuinjune, thank you for the feedback.

1. Happily "Shift" works again. I meant the functions that shift the grid one step into one direction. It did not work anymore because i needed to adjust the functions to the 2 dimensional table.
2. You are right, I do not need to return the table, i think your suggestion to do that internally with pd.Array() is the solution. Will try that tonight.
3. It is fine for me to write a 2-dimensional lua table to a 1 dimensional [array]. With "flatten" I meant to make a 1 dimensional table out of a 2 dimensional table. With "deflatten" I meant to make a 2 dimensional table out of a 1 dimensional table. I think I did not found the right terms for that.
4. Thanks. That was my mistake, it works again. I still think there is some strange behaviour under certain conditions with sending bangs into ofelia objects, but I am not sure anymore. I will check that and post a minimal patch if I still find that behaviour.

I would love to play around with these ideas, but none of the above patches work with Ofelia v3.1.0.
I tried to update the file ofelia-2-gridx.pd and made some small changes in order to make it work, but it doesn't seem to really work as expected; it doesn't show any graphics besides the background... I added some question marks where I'm not sure if I did the right thing.
Could you please take a look? Also, this is the first time for me uploading something here, so please excuse me, if I'm doing something silly 1544816749521-ofelia2_gridx-new.pd

@Shaker I already updated the patch, you can find it in another thread (third post): https://forum.pdpatchrepo.info/topic/11826/conways-game-of-life-made-with-ofelia/2 (you need to set generations to 1 to get midi output, because that patch is "optimized" for the game of life)