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.

@whale-av Huh that is interesting. I suppose you could also do something like this for a "lightweight" version:

@rjp9 That's true....... and a good idea to integrate the old random. I had been struggling with [time] without [random] and of course, apart from problems controlling the range, the time comes around again from time to time....... duh!...... so the randomness depended on the "bang rate". Your solution is better, although not vanilla? but it solves all of those problems (I think).........
David.

@whale-av Yeah I mean the algorithm of [random] is pretty good...there's just the inherent problem of a "default" seed as you have described. To me the solution would just be to find a way to (pseudo)randomize the seed.

Is there such a thing as "truly" random?

Some other useful random objects from the Extended library:

[urn]
[drunk]
[gauss]

Is there such a thing as "truly" random?

@LiamG is right, that trick of using CPU time or something like that does not output true random numbers: even with a randomly selected seed, there is still a deterministic formula behind the number generation. In some contexts (particularly people doing some computational physics) the aspects of a poor pseudo-number generator can be observed in the data (that is, they do not even look random to the trained eye).

If you want true randomness, you can use random.org, which uses atmospheric noise to generate numbers. Some Mr. smart-pants could still point out that weather, though very complicated, is still deterministic. And that would be true, though this type of system is so dependent on initial states that it soon turns into a chaotic system. And given that the "formula" behind the weather system of the planet Earth is incomparably more complicated than any pseudo-number generator we can think of, we basically can assume that it's as random as it gets.

I have also seen some people generating true random numbers using some crazy experiments such as radioactive decay time.

Anyway, I digress.

Cheers!
Gilberto

@gsagostinho Hello Gilberto.... that is why I was using the [noise~] object, although I do not know its underlying code...... I was hopeful, and so far I cannot see any patterns in my series.... but a pattern might be revealed at a specific bang rate............. I am now looking for a way to test properly the hypothesis.........
Anyway, anything is better than [random] on its own........ it is so depressing seeing the same numbers arriving every time a patch is opened.........
David.

@whale-av Hi David,

Well, fundamentally any noise generator is a pseudo-number generator since it uses deterministic mathematical formulas to achieve randomness. What I wrote about not looking so random can't be perceived just by looking at a bunch of numbers. The example I gave was with computational physics, and the point is that sometimes they need to generate a billion or a trillion random numbers to simulate something, and if the formula starts repeating after a number of outputs smaller than that you get a repetition in the data, and those patterns may (or may not) be observable by a trained eye.

I hope it's clear I am just being pedantic here, for any regular mortals these pseudo-number generators with seeds selected via computer clock are more than enough

Cheers,
Gilberto

As it is said above, even a good PRNG (such as Mersenne Twister for instance) will give the same sequence of number with the same seed. Computers are deterministic, that's the problem. For a non cryptographic usage you can use a mix of CPU time / pid to initialize it. I have no idea what is the PRNG used under the hood by the random object. It's not a classic LCG and googling it terms didn't match anything.

Thank you all...! I will concentrate on your idea @rjp9 but using elapsed time (for vanilla) so as to reseed at every bang......... and see if the probabilities are good over time.
The [random] object does not fulfil any requirement of the possible definitions of "random"..... except the equal probability of each number (in the set) if you run through the whole set.

It is a predetermined series calculated from a $0 seed......... and probably only one series with a modified start point..... that guarantees at least the probability of each number occurring!
Reseeding every bang uses more cpu than the dsp solution, and unsurprisingly produces patterns.
true random.zip
David.

AFAIK seeding a PRNG at each request don't increase randomness, it decrease randomness.

About testing PRNG ( http://www.johndcook.com/Beautiful_Testing_ch10.pdf ).

Pd tries to limit indeterminism in both its message timing and its object interfaces, so you're going to find it difficult to generate entropy.

However, you can use these control objects to generate some entropy:
[realtime] - use it to measure the time it takes to compute something (like iterating through a list, splitting a symbol, etc.). It tries to measure the actual time it took to do the calculation which will typically be different each time.
[textfile], [qlist], [soundfiler] - you can measure the time it takes to do file i/o with these objects using [realtime]. The time to do i/o can vary wildly on most OSes.

And this signal object:
[adc~]

You can use any or all of these to get a value that is different each time you run Pd. Once you have your value, send it as a seed to random:

[receive your_value]
|
[seed $1(
|
[random]

Now you can just bang random all you want. 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.

@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.