@oid This is great! I thought something like this should be possible, will have to study your patch a bit to get what's going on, but that definitely saves a bunch of manual labor when creating the grid.

And yeah, I didn't test it with unequal rows & columns. Probably something wrong with the expression.

So I ended up pretty much rewriting the whole thing.

@oid 's suggestion to handle the setup in its own abstraction with unitl was a game changer (pun very much intended )! The setup actually became redundant as I realized that I can just loop through the cells on each round using until and appropriate expressions. I used if-statements to clean up the expressions massively and moved almost everything outside the cells, which now only receive the number of neighbors, and, on the last round of the loop, a bang to update their state if necessary.

Good news: everything seems to work now, and the patches are much prettier than before.
Bad news: I still don't really understand what was wrong with the original version. But yeah, some weirdness must have been going on with the "custom loop" that the cells made up.

Here's my solution for anyone interested: game_of_life_v2.zip

Thanks for the help everyone! Next step: making the game play some music

Wow guys, thanks for all the super helpful suggestions! Been busy with work so I haven't had time to dive deeper into them but I'm now quite confident I'll be able to tackle the issue once I do over the weekend

All of the cells access nrows and ncols, in the expressions where the indices of the neighbors are computed, but shouldn't change them. The state of each cell, which is also stored as a variable, is also accessed by all of it's neighbors, but not every other cell (and this only happens once the game starts, not on setup). Otherwise there shouldn't be things shared across the cells.

So is it possible that a cell is still accessing ncols / nrows when it passes the bang forward to the next cell cell to start its setup, and somehow the order is mixed up there? I don't really know what Pd does in the background when accessing a variable, but I guess that could happen if the expressions only start fetching the variable and the cell-patch progresses in the background.

Thanks for the helpful comment, will have to look into $0 more!

Hi folks! I've been getting to know Pd and having a ton of fun doing it, but I've run into a pickle that is turning the fun more towards frustration
As my first project, I decided to build a musical version of Conway's Game of Life, and I even got a small version of it working, but trying to make the game a bit larger has stalled on a weird issue that I just can't seem to solve.

Basically, my "game" is made up of cells, which are abstractions that are identical in every way, except they take as a creation argument a number, which determines both the order in which the cells are processed, and their position in the game grid. When the game grid is loaded up, a bang goes to cell number 1, which reads its own creation argument and calculates based on that, and the number of rows and columns in the grid, which cells are its neighbors. It then sends a bang to cell 2, which does the same and sends a bang to cell 3 etc.
"Playing" the game works similarly, with cell 1 first calculating how many neighbors it has alive, and then telling cell 2 to do the same etc. Once the last cell is reached, a new bang is sent to cell 1 telling it to set its new state, and this instruction is again passed forward to cell 2 etc.

This all works fine in a 5-by-5 grid. In fact, I've even been able to "play" some music using this smaller version (and it sounds pretty fantastic as well!). However, if I increase the number of rows and columns to 10, I get a "stack overflow" error when I load the grid up. Specifically, I've located the problem to cell number 56: it still has all its neighbors set up properly, but cell number 57 no longer does, implying that somehow cell 56 fails to send 57 the instruction to set up. This is quite strange considering that there is nothing different about cell number 56 compared to the previous cells, which have all worked fine.
I've checked that the creation arguments are correct, and the neighbors get set up correctly (though even if they didn't, the setup shouldn't cause a stack overflow). I can't think of an issue with the order of operations either, as the setup is handled cell-by-cell.

All ideas on what could be causing this would be be greatly appreciated! If anyone wants to dig deeper, here is a zip with the cell-abstraction and two versions of the grid-patch: one with 25 cells (this works), and another with 100 cells (this doesn't): game_of_life.zip
(I've taken out all the code having to with actually playing music with that thing so it's easier to understand, so it's just the visual part of the game, but it works standalone.)