I think it's expected that if you don't provide it with a seed it will always have the same pattern of outputs. I can reproduce the behaviour with [random 10] in Pd 0.54 on my computer. Good thing with Bela is that you have some actual random noise sources available in the audio input and analog input, so you could use a snapshot of those to set the seed for your [random].
That's assuming seeds were implemented on the Pd version we are running on Bela. I think those were added more recently than the latest version of pd on Bela. Still, you can use a random input from the adc to advance the [random]
object by a "random" amount (e.g.: bang it hundreds of times depending on the value of a snapshot of the adc~. You won't get the same result as truly seeding the random generator, but hopefully you'll move far enough in the sequence that it will have the equivalent result.
Something like this:
Note that:
- the actual number of different "seeds" is the argument of the
[% ...]
object, assuming that the multiplier above it is enough to fill it up. If the number sent to [until] is too large, it may cause an underrun, but that could be acceptable as the patch just started. Making it larger than 65536 won't make sense because that'd be higher than the resolution of the noise.
- the 500 ms delay on boot may be excessive, the
[hip~ 5]
is probably much faster than that. Also, with the [%] operator in the loop, maybe we could get rid of the [hip~]
altogether.