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

ofelia test grid

@Cuinjune thanks for checking the patch. it crashes on my computer if the grid has more than ~1100 cells, except it is 1 * y or x * 1. i also tried to reinstall ofelia and pure data, but still. i wonder if anyone else can reproduce the crash? good idea with the abstractions, i updated it in the post above, its now vanilla (except ofelia).

@Jona Hi I could confirm that your patch crashes when I increase the size of the grid.
And I found out what is causing the crash.
I actually limited the size of the elements to 1000 when outputting a lua table through pd's outlet.
I thought this will only be a problem when users use more than 1000 userdata elements but now looking at my code, it is also problematic when using other types as elements.(e.g. number, string..)Anyways, I can easily fix this so it no longer have a limit.
I will fix this and upload 2.0.4 version to Deken by the end of this week and will let you know.Thank you.

@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/conwaysgameoflifeimplementationwithdatastructures 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/LuaGrid 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 1dimensional table into a 2dimensional 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 2dimensional 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 2dimensional 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 2dimensional 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!

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

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.

I'm not sure what would be the best way to save and recall a 2dimensional lua table in pd. Even if you have a 2dimensional 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 2dimensional array can become 1024 1dimensional array) And I don't know what you mean by flatten/deflatten the lua table.

I checked your patch and you are sending [invert( message into the "ofelia d c11 k $0Invert" 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.
 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.
 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.
 It is fine for me to write a 2dimensional 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.
 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.