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.

@jancsika Thank for the info..... I have a machine sitting testing at the moment for occurrence of a set of five numbers.
Using my true-random patch (5 times) it is producing a totally random chance that the set of numbers is produced. For each test it will produce somewhere between 1 bang and 3e+006 bangs so far, but there is (maybe) a chance that it will never produce. That is sufficiently random for my purposes. So far it has been a different number every time, but the test takes time and has only been running for a few days.
Using a seeded [random] it produces the sequence within the range of probability (5 to the power of 12) in this case........ or not at all. The problem with the [random] object is that it is a fixed series, with an equal distribution of numbers, but a series all the same, and the seed just shifts the series. Every time one creates a copy of [random] the series is shifted by 1 position.
I will build a patch soon to test for distribution and then maybe I will be finally happy. It will be strange if it proves to be that easy!
David.

It's still just a pseudo-random number generator, but the point is that you seeded it with a value that is different each time you run the patch. So for most musical purposes you can assume it's a real random-number generator from that point on.

Not too sure I agree with that, I also heard that reseeding is a bad idea because it easily leads to results that do not follow a probabilistic distribution (that is, the results will be all over the place). The proper way of using a PRNG is to seed once AFAIK.

Sorry, I'm not at a machine with Pd on it. An example patch would probably be easier.

I'm talking about generating the initial seed once, using the objects I mentioned to get a little bit of entropy for the seed. Once seeded, you just bang the same [random] to get out the values you want to use. I don't see how this would result in a distribution any different than what you would get without specifying the initial seed.

@whale-av: If your seed is truly random then why does it matter that you are dealing with a fixed series? I'm not implying it doesn't matter, just that there are a sufficient number of use-cases for this (like deterministic Bitcoin wallets) that it's not obvious why it wouldn't work in your case.

Sorry, I had misunderstood you, I though you were proposing an algorithm that would reseed each time you wanted a new random number. My mistake.

@jancsika There is absolutely nothing at all random about [random].......... every time you run it you get the same sequence (displaced if you seed it, and displaced if you have more than one instance)......... proof.........test-random.pd
Use the patch to start Pd (if you have random already open somewhere)...... i.e. please re-start Pd from scratch to run the patch..........
There are two tests........... the top bang (manual) shows the sequence.
The "Test" bang shows the second occurrence of the first sequence is at exactly 237343 bangs.
Both tests have to be run from a new opening of the patch (the normal situation for a patch.
David.

There is absolutely nothing at all random about [random].......... every time you run it you get the same sequence (displaced if you seed it, and displaced if you have more than one instance).........

That's just how a PRNG works.

@gsagostinho: Yeah I wish there was a Pd patch editing environment for the browser. The GUI I'm working on for the upcoming version of Pd-l2ork is done in HTML5 so maybe I can figure out a way to abstract that out...

@jancsika I use Pd-l2ork for all my work, it's such a wonderful distribution...

@whale-av said:

@jancsika There is absolutely nothing at all random about [random].......... every time you run it you get the same sequence (displaced if you seed it, and displaced if you have more than one instance)......... proof.........test-random.pd
Use the patch to start Pd (if you have random already open somewhere)...... i.e. please re-start Pd from scratch to run the patch..........
There are two tests........... the top bang (manual) shows the sequence.
The "Test" bang shows the second occurrence of the first sequence is at exactly 237343 bangs.
Both tests have to be run from a new opening of the patch (the normal situation for a patch.
David.

So you are saying that the seed only displaces the series? This is worrying indeed. Do you know how the displacement works, though? It doesn't seem to be linear, ie. "seed 2" doesn't seem to be "seed 1" + 1.

Maybe you could do something like this:

Of course it is still determined, but at least it will break the series that you have described above, if seeded properly with [time]. And if that's not enough then you can easily create n number of parallel randoms, or n depth layers...

One more thing: if you are set on using [noise~] for this, you should consider using [switch~] to turn DSP off in the subpatch after the output, in order to save CPU. Of course there's a chance that this too will affect the randomness though! Does [noise~] restart every time DSP is switched on? I haven't tested this, but it would be easy to do.

@LiamG Hello Liam......Yes, if you open test-random.pd (above) and delete the [random 12] sitting on its own at the top of the patch, and then save your patch as e.g. test2-random.pd and re-open Pd completely with the new test........... you will see the same series displaced. But this just means that the same seed will produce the same series, and the seeds are determined at creation (probably from $0).
So I don't know that the series is only displaced by the seed....... it's a hypothesis and I will work on a test patch.......
David.

@LiamG

So you are saying that the seed only displaces the series? This is worrying indeed.

But that's the very definition of a seed!

@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