I noticed a while back that [random] has the seed hard-coded into it, so while each newly instantiated [random] gets a unique seed, they're always going to be the same seeds relative to a full restart of pd. I made a slight variation called [rand] that uses the current time in seconds (0 - 86399) in the seeding process to prevent this.

[rand] also receives the message "peek", which will print x_state and the time value used during seeding. I also made it so that when "seed" is sent without a parameter, it seeds with the current time.

If you know of a similar object that someone else made or find any bugs in the code, be sure to let me know. I've used this on ubuntu and windows8 without running into any problems.

http://www.pdpatchrepo.info/hurleur/rand.zip

a bit different, but here's my seed generator patch:

http://puredata.hurleur.com/viewtopic.php?pid=38606#p38606

I really like the concept behind vanilla-random. I've been playing around with it and it seems like one of the drawbacks might be that the faster you churn out the numbers, the smaller the opening becomes for a delay? (that's my theory anyway), which results in recurring 1's and 0's.

But also, strangely enough, manually clicking a bang object instead of a bang message seems to make a difference. With the bang message, it's nowhere near as noticeable but with the bang object the 1's and 0's start showing up more frequently.

I also noticed that if I change the last multiplier from 1,000 to 10,000, the recurring numbers become 8 and 17. It's mysterious and I don't really know what it all means but if I don't tinker with the original design, it actually works quite well.

the idea is to use the vanilla random as a seed for normal [random] object. That way it only needs to be banged once, perhaps with a [loadbang]

But yeah, I threw it together by trial and error, so i just kept playing with stuff until i got what looked like a fairly random spread. Not sure how reliable it really is, but without any sort of

[rand] has been updated:

• You can specify two arguments for boundaries.
  • [rand 3 6] <- a number between 3 and 6 (3,4,5,6)
• You can specify more than two arguments to create a list of numbers.
  • [rand 2 3 5 7 11 13 17] <- a number between the first seven prime numbers.
  • more inlets will instantiate as more arguments are specified

You can download builds here: https://github.com/myQuil/pd-externals

edit: linux and darwin builds are now also available

Hi,

while each newly instantiated [random] gets a unique seed, they're always going to be the same seeds relative to a full restart of pd

I don't really understand this. I created the following patch:

[loadbang]
|
[random 100]
|
[print]

Each time I run the patch the result is different, even if I close Pd and restart it. In other words, full restarts do not generate the same seed. Am I missing something here?

Take care,
Gilberto

must be, the seed should be the same every time.
here I get 74 each time opening it

@seb-harmonik.ar Really? I am using pd-extended 0.43.4 64-bit with Linux Mint 17.1 and I don't have such problem (I just double checked it once again, all is good here).

my point is that it is not a problem but the desired behavior

@seb-harmonik.ar sure, I expressed myself badly above. I really want to figure out what is going on now because most (if not all) of my compositions in Pd are generative and use [random], so this would change everything...

If you look at the source code for [random] (x_misc.c) you'll see the seed in the makeseed function:

static unsigned int random_nextseed = 1489853723;

so changes made to random_nextseed will hold across all new instantiations of [random] because it's static, but after a full restart of pd, the int returns back to 1489853723

So I guess the explanation is that somehow pd is not fully restarting when I close it down and reopen it once again. I will have a further look on this, thanks for the information.

Hi all,

I just made some more tests today and it turns out I can't reproduce what happened yesterday! That is, today I always get 74 from [random 100] when restarting Pd, just like @seb-harmonik.ar did. I will download your external now and have a look on it, but I also would like to share a simple solution I came up with (using zexy's [time]):

Thanks for the help and take care,
Gilberto

@miwi I had a look on your externals, and they are absolutely amazing, thanks for sharing them! From now on I will probably be relying on [rand] and [grand] for my generative work. I also really appreciate you compiled them for all platforms, making it easy to share patches.

Take care,
Gilberto

Thank you miwi, sooner or later I will end up using it. It goes to my Favourites.

I built a special random object not long ago, which I never shared, but it was a different kind of thing, sthg I still need to improve.

If I don't understand how it works, I'll be asking you some questions!

Thanks guys, I'm really glad you like the objects.
There's actually one more I made just recently called [rind], which uses less logic, about as much as the original [random] except that with [random], a double value is created and is then cast to an int, whereas with [rind], the double value is left intact. It's somewhat analogous with leaving the rind on cheese, hence the name. It uses time for seeding and allows for one or two arguments (min and max).

Thanks miwi, I really enjoy this new object!

Take care,
Gilberto