I see that everyone is a bit busy at the moment but.......
Having been upset at seeing the same number sequence put out by [random] every time it starts (I know it can be reseeded.......? but)........... I have attempted a true random number generator with the same argument............. and built a simple test patch [true-random_help]
I missed that [random] carries 0 to n-1 and I made this 0 to n unfortunately. However that's easier to undo than it was to make it work.
It uses audio (I can't think of another way to do it) but is not too "heavy" I hope.
Any comments about the maths, the 0 to n, etc. especially from any of you statisticians.... will be very welcome......
true random.zip
David.

@gsagostinho Didn't know this--thanks for correcting me.

@LiamG The idea is as follows: a PRNG is basically a complicated enough but completely deterministic mathematical formula which outputs a series of numbers that "look" random, as well as having other properties (showing certain distribution characteristics, etc.). If you don't seed this function, it will always output the same values (as it's simply a deterministic function). But given that the period of a PRNG is fairly large, we can simply shift the initial position of the function to receive what looks like a completely different bunch of numbers, and that's what seeding does. If the effects of seeding are obvious (one can spot the shift) it means that the period of the PRNG is probably not large enough for what you want to do.

Here is a cool illustration of a pattern created by a PRNG: http://boallen.com/random-numbers.html

But as the author writes, notice that:

Not many PRNGs will produce an obvious visual pattern like this, it just so happens to be a really bad combination of language (PHP), operating system (Windows), and function (rand()).

@gsagostinho Hi, I couldn't help myself 60,000 size 1 canvases in a 500x500 pixel random pattern.
started pd-extended from a terminal, for safety.
Certainly upset Pd, the first 30,000 only 4 watchdog errors, second 30,000 heaps.

@whale-av What if the array is filled by "true noise" from adc?
-setting a threshold of the incoming signal with a limiter so that microphone volume is irrilevant;
-combine the table data and a saw-tooth wave in fm synthesis to generate both complexity and uniform distribution.
Can this be considered true random?
Thanks
fm random.pd

@deframmentazione-geometrica Yes, as discussed above [adc~] will be random (not in the scale of the universe of course) and distribution is then the problem if that is important to the project.
I seem to remember that the whole discussion started because someone wanted a true random for an android Pd app, and could not use the microphone..... hence looking for another solution.
And I remember correctly (more or less)...... it was you in this thread........ https://forum.pdpatchrepo.info/topic/11331/things-change-when-i-loadbang-the-process/3

However, if the microphone volume is irrelevent what characteristic of the signal will generate the random data?
David.

Here's a neat exercise that relates to hashing and cryptocurrencies:

Take the following object chain:

|
[seed $1, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang, bang(
|
[random 2]
|

We'll collect the output stream and use it to set the state of a 16-step rhythm sequencer.

0 equals no drum hit. 1 equals drum hit.

Now, consider that the Amen chorus might look like this in our crude sequencer:

1 0 1 0 1 0 0 1 0 1 1 0 1 1 0 1

Question: what seed value should we give to $1 so that our [random 2] outputs the Amen chorus?

@jancsika Brute-force gives 4481 and 19641

bruteforce.pd

@whale-av [adc~] gives some noise even without microphone, that noise is enough if moltiplied in amplitude, you don't need more volume, the limiter stabilize the incoming signal whatever the mic setting in your system.
I din't realize it was for an android app, I posted here because is based on your configuration.
What does this have to do with the old thread about [seed(?
Thanks

@ingox That's it!

Now, suppose that instead of the current spam protection on this forum, the admin did the following:

1. When a person wants to make a post, the forum sends a randomly chosen 16-beat pattern to the poster and requires the poster to send back the correct seed with their post
2. The poster uses your brute-force method to compute the correct seed and sends it back with their post
3. The forum software checks whether the seed actually computes the correct beat pattern. If it does then it lets the post through. If not, it blocks it.

Step 3 is easy-- just set the user's seed, send 16 bangs to [random 2] and check if the output matches.

Step 2 is hard-- in your case it took 4481 times through the loop to get the right answer.

Step 1 is easy-- most OSes have a way to spit out an unpredictable sequence of bits

Furthermore, if we add steps to the sequencer the job gets harder for the poster to find the seed, but it stays (relatively) easy for the forum website to verify the correct answer. That means the website can try different size sequencers to reach a nice balance between spam-prevention and user frustration.

Congratulations-- we've just re-invented hash cash, the key ingredient behind Bitcoin payment validations.

@deframmentazione-geometrica That in that thread I suggested noise from [adc~] as a random source (with a patch)....... that is all....
David.