What I was referring to is that one could equivalently write a counter in these two ways:
however, only the left hand side one will work forever. The right hand side one won't, because it doesn't wrap back to 0 the value that is stored into the
[f ], which means that if the patch runs for long enough, the number will eventually become big enough that it won't be represented well as a single-precision
float (which is what Pd uses internally) and it will start misbehaving. There are other cases where long-running patches start misbehaving, often triggered by something like this. However, this doesn't seem to be the case for your patch case, as the code in the screenshot has none of these problems, and as you are checking the values as soon as they are output by each sensor reader, I don't see how a problem elsewhere in the patch could cause that.
Unfortunately this means I have to look back at one of the ugliest parts in the Bela core code where this issue could be coming from ... Could you try your code with 1024 and 4096 block size? Does the issue persist and does it occur at the same point in time (i.e.: after 30 minutes)?
In the meantime, have you tried restarting the patch without restarting the board? This is done by tapping the button that's on the cape. That should give you about 2 seconds downtime instead of 10-15 that you'd get otherwise.