The sequences produced by random() are pseudo-random.
The seeding is the problem with the above mentioned sequence, not random(). Seeding has nothing to do with the distribution of results, it selects only the starting point in the fixed, pseudo-random sequence.
I read the 20 page PDF with interest, although most of it was over my head. A few decades ago perhaps….
As I’ve mentioned, my requirement is very simple: a fresh set of say 10 to 20 effectively random numbers on each startup. They represent folders of MP3 files, so I want unpredictability of play. I’m surprised that this is proving harder to achieve than I’d anticipated.
One possibility that wasn’t mentioned in the PDF that I’m wondering about is an LDR. I could mount one fairly unobtrusively on the top or side of the case. Do you think the variations would source a useful seed?
random and the seeding code at the end of the provided link will work well for that.
I suspect your definition of "fresh" means "don't play the same thing twice in a row". In which case, you'll want a random shuffle. Shuffling has been discussed many times here, there are copious resources available on the internet-at-large, and you're always welcome to ask for help.
You may also want to save the shuffled list to EEPROM. That would give a better overall "fresh" experience.
Another nicety might be to shuffle what remains when playing the last song in the list. That would guarantee the current song is not duplicated.
If the data is collected over a reasonable amount of time then maybe. But, a much simpler reliable solution has been provided.
Which means you got lucky. The AVR processor is perfectly deterministic. The only way micros can possibly work for seeding is when an external random event significantly alters the time at which the random number generator is seeded.
You cant judge whether a sequence is random on the basis of a dozen numbers. And a random sequence of numbers in the range 1-28 will be expected to have repeating sequences which is not what you want.
So as has been said, you will need to manipulate your results to force the kind of sequence you do want - where no number repeats in a short sequence. So for example you could put the used numbers into a short "black list" to prevent re-use until they are released.
random(a,b) needs a "seed" which is often generated like this
randomSeed(analogRead(0));
.. but the voltage on an unconnected analog pin is not reliably random.
It appears to vary by IDE version. There are other (presumably unrelated) issues about the first line of print sometimes being missing or corrupted.
Bottom line on this side issue: I'm fairly sure it's because I'm printing at such a fast rate. Even though the monitor is frozen it can then continue to update, blocking selection and copying.
I have indeed participated in topics where users had problems copying from the Serial monitor but the majority of them were caused by the user not copying the text properly or not understanding how to copy it using the keyboard
From my post #1:
"I was unable to copy/paste the frozen serial monitor text. (Sometimes I can!)"
More detail:
A program is uploaded via USB using IDE 1.8.19 to the 328 on the UNO and is executing as expected, including printing to the monitor. I freeze the auto-scrolling, and check there is no visible activity in the monitor, then select text either selectively by dragging or entirely with Ctrl+A. I then use Ctrl+C, which SOMETIMES does not copy it to the clipboard. The destination is either empty or just pastes the very first line. IOW, the same behaviour that's described in several of the references I listed.
Rarely, by excluding the first line of print I can succeed.
I assumed an obvious fix would be to pull the USB plug before the copy, but that made no difference.**
As I said, I'm now fairly confident that it's down to the fact that the monitor continues to get text even after auto scrolling is stopped. Assuming the monitor's scroll bar has not been moved beyond my PC's screen to make more space, the movement of the scroll button is often so slow as to seem static.
** Possibly, as I read in one of the many posts I've studied, that's a timing issue. IOW it depends on what happens first: the final print or my closure.
I am sure that you are right. The Ctrl+A can only select output that has already been printed, whether it is visible in the Serial monitor screen or not. So, if the output is being continually updated there may well be some that is not selected by Ctrl+A because it was printed afterwards. Hence, it will not be copied when Ctrl+C is used
If you really want to capture fast changing Serial output for debugging then the best solution is to use a third party terminal emulator such as CoolTerm and save the output to a text file as it arrives
The AVR processor is perfectly deterministic. The only way 