I want many (let's say 10) [random] objects that give different series of numbers each time the patch is loaded (of course, the 10 [random] give different series from each other). I tried using [time] and [date] objects to generate different seeds, but the same seed (different on each load) is given to the 10 [random]. I tried using a mix of [date], [time] and [realtime], but it's quite unreliable. Any ideas? Thanks Ignacio
Ignacio Viano wrote:
I want many (let's say 10) [random] objects that give different series of numbers each time the patch is loaded (of course, the 10 [random] give different series from each other). I tried using [time] and [date] objects to generate different seeds, but the same seed (different on each load) is given to the 10 [random]. I tried using a mix of [date], [time] and [realtime], but it's quite unreliable. Any ideas?
the problem is of course, that when opening your patch everything happens at the same logical time; so seeding your [random]s with [time] (and the like), you will actually seed them all with the same seed, thus producing the same series in all instances of [random]. using [time]+[realtime] should in theory work; another idea would be to add a different offset to the basic [time] derived seed for each [random]: so all seeds are different (though related), which should work fine.
the really nice solution would be to use a [time]seeded [random] to generate the seeds for the other [random]s.
fgmasrd IOhannes
IOhannes m zmölnig wrote:
Ignacio Viano wrote:
I want many (let's say 10) [random] objects that give different series of numbers each time the patch is loaded (of course, the 10 [random] give different series from each other). I tried using [time] and [date] objects to generate different seeds, but the same seed (different on each load) is given to the 10 [random]. I tried using a mix of [date], [time] and [realtime], but it's quite unreliable. Any ideas?
the problem is of course, that when opening your patch everything happens at the same logical time; so seeding your [random]s with [time] (and the like), you will actually seed them all with the same seed, thus producing the same series in all instances of [random]. using [time]+[realtime] should in theory work; another idea would be to add a different offset to the basic [time] derived seed for each [random]: so all seeds are different (though related), which should work fine.
the really nice solution would be to use a [time]seeded [random] to generate the seeds for the other [random]s.
Or have a single random generator inside pd that feeds all the random objects. Also /dev/hwrandom on some machines will give 'real' random numbers that don't need to be seeded.
Martin
In a way~, it's not so straightforward. Let's say the random generators are identical and seeded by another identical random generator with no further modifications. Then, all the other random generators are correlated--using the same sequence, but with slightly different starting points within that sequence.
so, you need to have a map of the range of random onto itself, which is different from the random sequence mapping. That way, you actually obtain seed values which are spaced far apart in the sequence.
This could be actually pretty simple, e.g. seed=rand_max - input_from_1st_rand
Chuck
On Thu, Sep 4, 2008 at 12:39 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
Martin Peach wrote:
Or have a single random generator inside pd that feeds all the random objects.
yes of course, this would be the most straight forward solution.
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Would $0 instantiation variables be of use here? Or would that make each random generator one value away from the one beside it?
d.
Charles Henry wrote:
In a way~, it's not so straightforward. Let's say the random generators are identical and seeded by another identical random generator with no further modifications. Then, all the other random generators are correlated--using the same sequence, but with slightly different starting points within that sequence.
so, you need to have a map of the range of random onto itself, which is different from the random sequence mapping. That way, you actually obtain seed values which are spaced far apart in the sequence.
This could be actually pretty simple, e.g. seed=rand_max - input_from_1st_rand
Chuck
On Thu, Sep 4, 2008 at 12:39 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
Martin Peach wrote:
Or have a single random generator inside pd that feeds all the random objects.
yes of course, this would be the most straight forward solution.
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Derek Holzer hat gesagt: // Derek Holzer wrote:
Would $0 instantiation variables be of use here? Or would that make each random generator one value away from the one beside it?
Probably yes, but it may lead to a nice "phasing" effect. ;)
IOhannes' suggestion of seeing one random which seeds the other objects is the way to go IMO.
Frank
On Thu, Sep 4, 2008 at 1:28 PM, Derek Holzer derek@umatic.nl wrote:
Would $0 instantiation variables be of use here? Or would that make each random generator one value away from the one beside it?
not a bad idea--because each random generator would be far apart in sequence--no correlation between the sequences. However, it doesn't solve the original problem, making them different between loads of the patch.
d.
Charles Henry wrote:
In a way~, it's not so straightforward. Let's say the random generators are identical and seeded by another identical random generator with no further modifications. Then, all the other random generators are correlated--using the same sequence, but with slightly different starting points within that sequence.
so, you need to have a map of the range of random onto itself, which is different from the random sequence mapping. That way, you actually obtain seed values which are spaced far apart in the sequence.
This could be actually pretty simple, e.g. seed=rand_max - input_from_1st_rand
Chuck
On Thu, Sep 4, 2008 at 12:39 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
Martin Peach wrote:
Or have a single random generator inside pd that feeds all the random objects.
yes of course, this would be the most straight forward solution.
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 24: "Bridges -build -burn"
On Thu, Sep 4, 2008 at 1:28 PM, Derek Holzer derek@umatic.nl wrote:
Would $0 instantiation variables be of use here? Or would that make each random generator one value away from the one beside it?
not a bad idea--because each random generator would be far apart in sequence--no correlation between the sequences. However, it doesn't solve the original problem, making them different between loads of the patch.
Perhaps i am getting you wrong, but if i would want different behavior each time i'd open that patch, the noise from your adc~ would do that, bc it is surely different (thermal noise, etc) every time. (provided you switched your dsp~ on in advance). :-)
rgrds, PP
d.
Charles Henry wrote:
In a way~, it's not so straightforward. Let's say the random generators are identical and seeded by another identical random generator with no further modifications. Then, all the other random generators are correlated--using the same sequence, but with slightly different starting points within that sequence.
so, you need to have a map of the range of random onto itself, which is different from the random sequence mapping. That way, you actually obtain seed values which are spaced far apart in the sequence.
This could be actually pretty simple, e.g. seed=rand_max - input_from_1st_rand
Chuck
On Thu, Sep 4, 2008 at 12:39 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
Martin Peach wrote:
Or have a single random generator inside pd that feeds all the random objects.
yes of course, this would be the most straight forward solution.
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 24: "Bridges -build -burn"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Sep 4, 2008 at 4:29 PM, Peter Plessas plessas@mur.at wrote:
Perhaps i am getting you wrong, but if i would want different behavior each time i'd open that patch, the noise from your adc~ would do that, bc it is surely different (thermal noise, etc) every time. (provided you switched your dsp~ on in advance). :-)
rgrds, PP
Yes, your method would work pretty well. The individual samples of the noise are correlated with each other (thermal noise is not white). But when you take a single sample at a given time without knowing the previous values, that correlation can be ignored, and you would generate a completely independent random number, drawn from the distribution of the noise. The only problem is if the noise is very narrowly distributed, so that you only recieve one of a few possible choices of the seed value.
Compared to using time/date: the noise we can assume is distributed about 0 with a Gaussian (continuous) or approximately a Binomial (discrete) distribution. On the other hand, time/date are distributed uniformly. You would have a greater variance of seed values from using time/date than by using noise from adc~, and thus, a lesser degree of correlation between instances.
I like your idea, because you really get a completely independent random variable--but I would try to convince you that, for a large number of instances, you would see some correlations in the sequences.
Chuck
One trick that works in patches that have some human interaction: loadbang a timer, then as soon as some human-generated input happens, grab the interval from the timer and use that for a seed.
Of course, this is no use for completely automated setups.
Phil Stone www.pkstonemusic.com
On Thu, Sep 4, 2008 at 4:29 PM, Peter Plessas plessas@mur.at wrote:
Perhaps i am getting you wrong, but if i would want different behavior each time i'd open that patch, the noise from your adc~ would do that, bc it is surely different (thermal noise, etc) every time. (provided you switched your dsp~ on in advance). :-)
...
I like your idea, because you really get a completely independent random variable--but I would try to convince you that, for a large number of instances, you would see some correlations in the sequences.
That is right, for really large numbers and critical applications the noise from the soundcard might not be white enough!
thanks!
PP
Chuck
On Thu, Sep 4, 2008 at 5:09 PM, Peter Plessas plessas@mur.at wrote:
- Charles Henry czhenry@gmail.com [2008-09-04 23:53]:
On Thu, Sep 4, 2008 at 4:29 PM, Peter Plessas plessas@mur.at wrote:
Perhaps i am getting you wrong, but if i would want different behavior each time i'd open that patch, the noise from your adc~ would do that, bc it is surely different (thermal noise, etc) every time. (provided you switched your dsp~ on in advance). :-)
That is right, for really large numbers and critical applications the noise from the soundcard might not be white enough!
Actually, it's not the whiteness of the noise which is important. Whiteness of noise simply means that the samples are not correlated with each other with respect to time. The key is the distribution of a random variable, namely the instantaneous value of the noise at a single point in time.
Since the noise values tend to be close to 0, the values are un-evenly distributed. I'm really just pointing to the advantage of using a uniformly distributed random variable for choosing seeds.
Of course, now that you have me thinking about it :) , we could transform our distribution for the noise into a uniform distribution, like using the Box-Muller method backwards.
Charles Henry wrote:
On Thu, Sep 4, 2008 at 5:09 PM, Peter Plessas plessas@mur.at wrote:
- Charles Henry czhenry@gmail.com [2008-09-04 23:53]:
On Thu, Sep 4, 2008 at 4:29 PM, Peter Plessas plessas@mur.at wrote:
Perhaps i am getting you wrong, but if i would want different behavior each time i'd open that patch, the noise from your adc~ would do that, bc it is surely different (thermal noise, etc) every time. (provided you switched your dsp~ on in advance). :-)
That is right, for really large numbers and critical applications the noise from the soundcard might not be white enough!
Actually, it's not the whiteness of the noise which is important. Whiteness of noise simply means that the samples are not correlated with each other with respect to time. The key is the distribution of a random variable, namely the instantaneous value of the noise at a single point in time.
Since the noise values tend to be close to 0, the values are un-evenly distributed. I'm really just pointing to the advantage of using a uniformly distributed random variable for choosing seeds.
Of course, now that you have me thinking about it :) , we could transform our distribution for the noise into a uniform distribution, like using the Box-Muller method backwards.
Attached is a patch that takes a low order bit from the sampled adc every 10 milliseconds to make a 16-bit number from 16 successive bits. Then it fills a table with 1000000 such numbers. After letting it run all night, this morning I had an array that certainly _sounds_ white. It would be interesting to run some tests on it. The sound card input was not connected to anything. The choice of which bit to sample is important and probably varies among sound cards.
Martin
#N canvas 778 48 352 556 10; #X obj 77 120 adc~; #X obj 76 144 snapshot~; #X obj 136 47 metro 10; #X obj 163 107 f; #X obj 197 90 + 1; #X obj 10 -11 sel 1; #X msg 10 8 0; #X msg 178 67 0; #X obj 76 185 i; #X obj 76 225 == 0; #X obj 76 205 & 4; #X obj 76 164 * 32768; #X obj 136 0 t f b; #X msg 136 -20 1; #X obj 199 160 expr pow(2 , $f1); #X obj 119 242 *; #X obj 136 67 t b b; #X obj 119 284 f; #X obj 119 263 +; #X floatatom 119 312 7 0 0 0 - - -; #X obj 10 -31 >= 15; #X obj 207 -37 metro 1000; #X obj 207 -57 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 90 315 f; #X obj 10 30 t f b; #X obj 190 132 t f f; #X obj 37 245 delay 10; #X obj 90 342 tabwrite pig; #X obj 207 277 f; #X obj 241 260 + 1; #X floatatom 207 298 5 0 0 0 - - -; #X obj 228 420 /~ 65536; #X obj 227 457 dac~; #X obj 228 399 tabread4~ pig; #X obj 230 358 phasor~; #X floatatom 230 339 5 0 0 0 - - -; #X floatatom 280 358 5 0 0 0 - - -; #X floatatom 264 -58 5 0 0 0 - - -; #X obj 229 378 *~ 100000; #X obj 241 279 % 100000; #X obj 90 362 table pig 100000; #X connect 0 0 1 0; #X connect 1 0 11 0; #X connect 2 0 16 0; #X connect 3 0 4 0; #X connect 3 0 25 0; #X connect 4 0 3 1; #X connect 5 0 6 0; #X connect 6 0 24 0; #X connect 7 0 17 0; #X connect 7 0 3 1; #X connect 8 0 10 0; #X connect 9 0 15 0; #X connect 10 0 9 0; #X connect 11 0 8 0; #X connect 12 0 2 0; #X connect 12 1 7 0; #X connect 13 0 12 0; #X connect 14 0 15 1; #X connect 15 0 18 0; #X connect 16 0 1 0; #X connect 16 1 3 0; #X connect 17 0 18 1; #X connect 17 0 19 0; #X connect 17 0 23 1; #X connect 18 0 17 0; #X connect 20 0 5 0; #X connect 21 0 13 0; #X connect 21 0 28 0; #X connect 22 0 21 0; #X connect 23 0 27 0; #X connect 24 0 2 0; #X connect 24 1 26 0; #X connect 25 0 20 0; #X connect 25 1 14 0; #X connect 26 0 23 0; #X connect 28 0 29 0; #X connect 28 0 30 0; #X connect 28 0 27 1; #X connect 29 0 39 0; #X connect 31 0 32 0; #X connect 31 0 32 1; #X connect 33 0 31 0; #X connect 34 0 38 0; #X connect 35 0 34 0; #X connect 36 0 38 1; #X connect 37 0 21 1; #X connect 38 0 33 0; #X connect 39 0 28 1;
Charles Henry wrote:
In a way~, it's not so straightforward. Let's say the random generators are identical and seeded by another identical random generator with no further modifications. Then, all the other random generators are correlated--using the same sequence, but with slightly different starting points within that sequence.
btw, this is how Pd's random generator (and [noise~], btw) works anyhow: there is only a single built-in pseudo-random sequence and all you can modify is the starting point.
but you are right insofar as my original suggestion of using one [random] to seed the other [random]s probably exposes this problem more than other approaches (incrementing the seed by one for each instance).
my last suggestion was about using a _single_ [random] and query that from all instances of [myrandom]; which should behave way batter (i think)
fgmasdr IOhannes
Hallo, IOhannes m zm?lnig hat gesagt: // IOhannes m zm?lnig wrote:
Martin Peach wrote:
Or have a single random generator inside pd that feeds all the random objects.
yes of course, this would be the most straight forward solution.
Only to this one problem, but it would lead to many others: Being able to seed [random] objects separately is a very important feature. For example a lot of the algorithmic composition in the game "Spore" is relying on seeding random generators separately with known seeds (according to the talk once posted here).
In Lua there is only one seed for all math.random() calls, and it's even globally affecting all pd_lua objects. That's very annoying, but thank god, there's a random.so "external" Lua module which fixes this.
Frank Barknecht
Speaking of Lua and randoms, I had read somewhere (I think on the website) that on some platforms, their random generators will always produce the same FIRST number, but everything else after that is "random". I tested this out on the Mac OS X, and yes, every FIRST number is the same, but everything else beyond that isn't. The "workaround" for this is to just drop the first random value you get. I don't know why this happens, but is it possible that the same things happens in PD? I have not tested this out.
Mike
On Thu, Sep 4, 2008 at 2:56 PM, Frank Barknecht fbar@footils.org wrote:
Hallo, IOhannes m zm?lnig hat gesagt: // IOhannes m zm?lnig wrote:
Martin Peach wrote:
Or have a single random generator inside pd that feeds all the random objects.
yes of course, this would be the most straight forward solution.
Only to this one problem, but it would lead to many others: Being able to seed [random] objects separately is a very important feature. For example a lot of the algorithmic composition in the game "Spore" is relying on seeding random generators separately with known seeds (according to the talk once posted here).
In Lua there is only one seed for all math.random() calls, and it's even globally affecting all pd_lua objects. That's very annoying, but thank god, there's a random.so "external" Lua module which fixes this.
Ciao
Frank Barknecht
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
Speaking of Lua and randoms, I had read somewhere (I think on the website) that on some platforms, their random generators will always produce the same FIRST number, but everything else after that is "random". I tested this out on the Mac OS X, and yes, every FIRST number is the same, but everything else beyond that isn't.
On Linux I get the same values not only for the first, but for all random values, unless I seed with os.time, and then the first value is different everytime, too.
But as globally seeded randoms are unusable for many composition algorithms, I prefer the random module from here: http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/index.html which lets you create the equivalent of Pd's independent [random] objects in Lua.
Frank Barknecht _ ______footils.org__
Hi, what do you think about using the (white) background hiss of your adc~ soundcard input? Make a snapshot at different intervals, one for each seed. (not tested myself).
good luck, PP
I want many (let's say 10) [random] objects that give different series of numbers each time the patch is loaded (of course, the 10 [random] give different series from each other). I tried using [time] and [date] objects to generate different seeds, but the same seed (different on each load) is given to the 10 [random]. I tried using a mix of [date], [time] and [realtime], but it's quite unreliable. Any ideas? Thanks Ignacio
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
And you could listen for ghost voices at the same time.....
;-)
d.
Peter Plessas wrote:
Hi, what do you think about using the (white) background hiss of your adc~ soundcard input? Make a snapshot at different intervals, one for each seed. (not tested myself).
good luck, PP
- Ignacio Viano ignacioviano@gmail.com [2008-09-04 19:11]:
I want many (let's say 10) [random] objects that give different series of numbers each time the patch is loaded (of course, the 10 [random] give different series from each other). I tried using [time] and [date] objects to generate different seeds, but the same seed (different on each load) is given to the 10 [random]. I tried using a mix of [date], [time] and [realtime], but it's quite unreliable. Any ideas? Thanks Ignacio
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list