dear all,
just started studying PD. going through the control examples i've been stuck trying to figure out the function of the message, seed 123 in the example for "random".
not sure if i figured out the explanation below,
Seeds are kept locally so that if two Randoms are seeded the same they will have the same output (or indeed you can seed the same one twice to repeat the output.)
would appreciate any help, thank much y'all, cheers, :)
Cem Güney www.myspace.com/cemguney www.last.fm/music/Cem+Güney www.soundtransit.nl/ impulse.tumblr.com/ www.cronicaelectronica.org/
Hallo, cem guney hat gesagt: // cem guney wrote:
just started studying PD. going through the control examples i've been stuck trying to figure out the function of the message, seed 123 in the example for "random". Â
not sure if i figured out the explanation below,
Seeds are kept locally so that if two Randoms are seeded the same they will have the same output (or indeed you can seed the same one twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is cloudy there?
If you send a "seed 123" to [random], then on my machine the next random numbers are "3 1 4 0 ..." If I send "seed 123" again, it starts again with "3 1 4 0 ..." If I send "seed 120128", I get "0 1 0 2 2 ..." instead each time afterwards.
Ciao
Frank
Frank Barknecht wrote:
Hallo, cem guney hat gesagt: // cem guney wrote:
just started studying PD. going through the control examples i've been stuck trying to figure out the function of the message, seed 123 in the example for "random".
not sure if i figured out the explanation below,
Seeds are kept locally so that if two Randoms are seeded the same they will have the same output (or indeed you can seed the same one twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is cloudy there?
probably the simple fact, that [random] despite of it's name does not really produce random numbers. mostly when computers present you a "random" number, then this number will only appear to be random, but in reality is just calculated as the next item of a totally deterministic series. (as a matter of fact, a new random number is usually generated by simple taking the last number and then applying some more or less complicated transformation on this number). this method is known as "pseudo random".
you can set the "starting point" of the series by setting the "seed", which is the first number of the random sequence). since all [random] object use the same algorithm to calculate the next pseudo-random number, they will all end up with the same sequence if they all start with the same "seed". by default Pd uses different seeds for all [random] objects so they all appear to work independently.
mfgasdr IOhannes
IOhannes m zmölnig wrote:
Frank Barknecht wrote:
Hallo, cem guney hat gesagt: // cem guney wrote:
just started studying PD. going through the control examples i've been stuck trying to figure out the function of the message, seed 123 in the example for "random". not sure if i figured out the explanation below,
Seeds are kept locally so that if two Randoms are seeded the same they will have the same output (or indeed you can seed the same one twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is cloudy there?
probably the simple fact, that [random] despite of it's name does not really produce random numbers. mostly when computers present you a "random" number, then this number will only appear to be random, but in reality is just calculated as the next item of a totally deterministic series. (as a matter of fact, a new random number is usually generated by simple taking the last number and then applying some more or less complicated transformation on this number). this method is known as "pseudo random".
you can set the "starting point" of the series by setting the "seed", which is the first number of the random sequence). since all [random] object use the same algorithm to calculate the next pseudo-random number, they will all end up with the same sequence if they all start with the same "seed". by default Pd uses different seeds for all [random] objects so they all appear to work independently.
In addition, it's probably worth mentioning that Pd will produce the same seeds for each [random] every time you load the patch. So while they appear to work independently, you will still get the same results each time you first run a patch after loading it.
.mmb
mfgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mike Moser-Booth wrote:
IOhannes m zmölnig wrote:
Frank Barknecht wrote:
Hallo, cem guney hat gesagt: // cem guney wrote:
just started studying PD. going through the control examples i've been stuck trying to figure out the function of the message, seed 123 in the example for "random". not sure if i figured out the explanation below,
Seeds are kept locally so that if two Randoms are seeded the same they will have the same output (or indeed you can seed the same one twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is cloudy there?
probably the simple fact, that [random] despite of it's name does not really produce random numbers. mostly when computers present you a "random" number, then this number will only appear to be random, but in reality is just calculated as the next item of a totally deterministic series. (as a matter of fact, a new random number is usually generated by simple taking the last number and then applying some more or less complicated transformation on this number). this method is known as "pseudo random".
you can set the "starting point" of the series by setting the "seed", which is the first number of the random sequence). since all [random] object use the same algorithm to calculate the next pseudo-random number, they will all end up with the same sequence if they all start with the same "seed". by default Pd uses different seeds for all [random] objects so they all appear to work independently.
In addition, it's probably worth mentioning that Pd will produce the same seeds for each [random] every time you load the patch. So while they appear to work independently, you will still get the same results each time you first run a patch after loading it.
A lot of the latest cpus have hardware random number generators that work by having a jittery oscillator sample the cpu clock, or something along those lines. (Such a jittery oscillator is assumed to have normally distributed transition times.) It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite.
Martin
hi,
thanks much for your response!
also in regards to your explanation,
"It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite"
any application examples as to why it would be nice if the random source could be independently specified?
cheers, :)
Cem Güney myspace. . lastfm. . tumblr. . cronica
From: Martin Peach martin.peach@sympatico.ca To: Mike Moser-Booth mmoserbooth@gmail.com Cc: pd-list@iem.at; IOhannes m zmölnig zmoelnig@iem.at Sent: Sunday, July 5, 2009 7:22:51 AM Subject: Re: [PD] help_random/seed
Mike Moser-Booth wrote:
IOhannes m zmölnig wrote:
Frank Barknecht wrote:
Hallo, cem guney hat gesagt: // cem guney wrote:
just started studying PD. going through the control examples i've been stuck trying to figure out the function of the message, seed 123 in the example for "random". not sure if i figured out the explanation below,
Seeds are kept locally so that if two Randoms are seeded the same they will have the same output (or indeed you can seed the same one twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is cloudy there?
probably the simple fact, that [random] despite of it's name does not really produce random numbers. mostly when computers present you a "random" number, then this number will only appear to be random, but in reality is just calculated as the next item of a totally deterministic series. (as a matter of fact, a new random number is usually generated by simple taking the last number and then applying some more or less complicated transformation on this number). this method is known as "pseudo random".
you can set the "starting point" of the series by setting the "seed", which is the first number of the random sequence). since all [random] object use the same algorithm to calculate the next pseudo-random number, they will all end up with the same sequence if they all start with the same "seed". by default Pd uses different seeds for all [random] objects so they all appear to work independently.
In addition, it's probably worth mentioning that Pd will produce the same seeds for each [random] every time you load the patch. So while they appear to work independently, you will still get the same results each time you first run a patch after loading it.
A lot of the latest cpus have hardware random number generators that work by having a jittery oscillator sample the cpu clock, or something along those lines. (Such a jittery oscillator is assumed to have normally distributed transition times.) It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
cem guney wrote:
hi,
thanks much for your response!
also in regards to your explanation,
"It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite"
any application examples as to why it would be nice if the random source could be independently specified?
Well I think it's mainly a philosophical thing about the meaning of 'random', but probably there are sequence generators for music that sound different with 'truly' random vs pseudo-random numbers. Sometimes you may want a repeating chaotic sequence, sometimes a completely random one.
For cryptography, as in a one-time pad, pseudo-random is relatively easy to crack. There are at most 65536 different sequences with typical pseudo-random generators, but that's not any inherent limitation of pseudo-random, just the particular implementation that's often used.
Also with games like rolling dice or shuffling cards, you probably want it to be completely unpredictable, or regular players will begin to recognize patterns.
Pseudo-random white noise playing at audio rate will actually be a repeating waveform several minutes or hours long. It's up to you if that matters or not.
Martin
To be honest an oscillator in that setting might do the job just as well, just so long as the figure isn't requested with the same regularity as the oscillation.
Date: Sun, 5 Jul 2009 12:44:05 -0400 From: martin.peach@sympatico.ca To: cemthemuteguney@yahoo.com CC: pd-list@iem.at Subject: Re: [PD] help_random/seed
cem guney wrote:
hi,
thanks much for your response!
also in regards to your explanation,
"It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite"
any application examples as to why it would be nice if the random source could be independently specified?
Well I think it's mainly a philosophical thing about the meaning of 'random', but probably there are sequence generators for music that sound different with 'truly' random vs pseudo-random numbers. Sometimes you may want a repeating chaotic sequence, sometimes a completely random one.
For cryptography, as in a one-time pad, pseudo-random is relatively easy to crack. There are at most 65536 different sequences with typical pseudo-random generators, but that's not any inherent limitation of pseudo-random, just the particular implementation that's often used.
Also with games like rolling dice or shuffling cards, you probably want it to be completely unpredictable, or regular players will begin to recognize patterns.
Pseudo-random white noise playing at audio rate will actually be a repeating waveform several minutes or hours long. It's up to you if that matters or not.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
With Windows Live, you can organise, edit, and share your photos. http://clk.atdmt.com/UKM/go/134665338/direct/01/
Andrew Faraday wrote:
To be honest an oscillator in that setting might do the job just as well, just so long as the figure isn't requested with the same regularity as the oscillation.
Yes, it's a subjective thing. The attached patch makes a sequence of 1s and 0s. You need to pack them into 16s to get the usual 0-65535 range. The output will be more random than the input [noise~], but it probably sounds exactly the same if you play it back at the audio rate.
Martin
Date: Sun, 5 Jul 2009 12:44:05 -0400 From: martin.peach@sympatico.ca To: cemthemuteguney@yahoo.com CC: pd-list@iem.at Subject: Re: [PD] help_random/seed
cem guney wrote:
hi,
thanks much for your response!
also in regards to your explanation,
"It would be nice if the random source could be independently
specified
for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite"
any application examples as to why it would be nice if the random
source
could be independently specified?
Well I think it's mainly a philosophical thing about the meaning of 'random', but probably there are sequence generators for music that sound different with 'truly' random vs pseudo-random numbers. Sometimes you may want a repeating chaotic sequence, sometimes a completely random one.
For cryptography, as in a one-time pad, pseudo-random is relatively easy to crack. There are at most 65536 different sequences with typical pseudo-random generators, but that's not any inherent limitation of pseudo-random, just the particular implementation that's often used.
Also with games like rolling dice or shuffling cards, you probably want it to be completely unpredictable, or regular players will begin to recognize patterns.
Pseudo-random white noise playing at audio rate will actually be a repeating waveform several minutes or hours long. It's up to you if that matters or not.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Beyond Hotmail - see what else you can do with Windows Live. Find out more. http://clk.atdmt.com/UKM/go/134665375/direct/01/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 511 273 694 304 10; #X obj 170 151 osc~; #X obj 168 80 noise~; #X obj 169 128 *~ 100000; #X obj 169 106 +~ 2; #X obj 171 211 snapshot~; #X obj 171 252 nbx 5 14 -1e+037 1e+037 0 0 empty empty empty 0 -8 0 10 -262144 -1 -1 0 256; #X obj 171 231 > 0; #X obj 19 42 metro 0.02; #X obj 19 20 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 19 -1 loadbang; #X text 215 79 start with pseudorandom noise on [-1...1]; #X text 207 104 make it on [1...2]; #X text 233 126 make it on [100000...200000]; #X text 203 151 the high frequency jittery oscillator; #X text 91 42 the low frequency sampling oscillator; #X text 229 250 a more random sequence of 0s and 1s; #X text 234 0 A "pseudo-hardware" random generator; #X connect 0 0 4 0; #X connect 1 0 3 0; #X connect 2 0 0 0; #X connect 3 0 2 0; #X connect 4 0 6 0; #X connect 6 0 5 0; #X connect 7 0 4 0; #X connect 8 0 7 0; #X connect 9 0 8 0;
it's nice to observe that an extensive/productive conversation has come about from my question in regards to "random" systems, and it's quite informative to follow, and frankly a bit far from my current reach of knowledge, but what is important for me at the moment is to learn the general difference between random & pseudo-random & the various applications that is possible with random systems via the several examples given. will try to build from there...
thanks again folks, :)
Cem Güney myspace. . lastfm. . tumblr. . cronica
From: Martin Peach martin.peach@sympatico.ca To: cem guney cemthemuteguney@yahoo.com Cc: pd list pd-list@iem.at Sent: Sunday, July 5, 2009 7:44:05 PM Subject: Re: [PD] help_random/seed
cem guney wrote:
hi, thanks much for your response! also in regards to your explanation, "It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite" any application examples as to why it would be nice if the random source could be independently specified?
Well I think it's mainly a philosophical thing about the meaning of 'random', but probably there are sequence generators for music that sound different with 'truly' random vs pseudo-random numbers. Sometimes you may want a repeating chaotic sequence, sometimes a completely random one.
For cryptography, as in a one-time pad, pseudo-random is relatively easy to crack. There are at most 65536 different sequences with typical pseudo-random generators, but that's not any inherent limitation of pseudo-random, just the particular implementation that's often used.
Also with games like rolling dice or shuffling cards, you probably want it to be completely unpredictable, or regular players will begin to recognize patterns.
Pseudo-random white noise playing at audio rate will actually be a repeating waveform several minutes or hours long. It's up to you if that matters or not.
Martin
Just an idea, but if the hardware random number generators use a jittery oscillator etc. Why not use [noise~] and [snapshot~] followed by some arithmetic and [int] you could build what I assume would be more random than the [random] box. Andrew
Date: Sun, 5 Jul 2009 00:22:51 -0400 From: martin.peach@sympatico.ca To: mmoserbooth@gmail.com CC: pd-list@iem.at; zmoelnig@iem.at Subject: Re: [PD] help_random/seed
Mike Moser-Booth wrote:
IOhannes m zmölnig wrote:
Frank Barknecht wrote:
Hallo, cem guney hat gesagt: // cem guney wrote:
just started studying PD. going through the control examples i've been stuck trying to figure out the function of the message, seed 123 in the example for "random". not sure if i figured out the explanation below,
Seeds are kept locally so that if two Randoms are seeded the same they will have the same output (or indeed you can seed the same one twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is cloudy there?
probably the simple fact, that [random] despite of it's name does not really produce random numbers. mostly when computers present you a "random" number, then this number will only appear to be random, but in reality is just calculated as the next item of a totally deterministic series. (as a matter of fact, a new random number is usually generated by simple taking the last number and then applying some more or less complicated transformation on this number). this method is known as "pseudo random".
you can set the "starting point" of the series by setting the "seed", which is the first number of the random sequence). since all [random] object use the same algorithm to calculate the next pseudo-random number, they will all end up with the same sequence if they all start with the same "seed". by default Pd uses different seeds for all [random] objects so they all appear to work independently.
In addition, it's probably worth mentioning that Pd will produce the same seeds for each [random] every time you load the patch. So while they appear to work independently, you will still get the same results each time you first run a patch after loading it.
A lot of the latest cpus have hardware random number generators that work by having a jittery oscillator sample the cpu clock, or something along those lines. (Such a jittery oscillator is assumed to have normally distributed transition times.) It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Get the best of MSN on your mobile http://clk.atdmt.com/UKM/go/147991039/direct/01/
Hallo, Andrew Faraday hat gesagt: // Andrew Faraday wrote:
Just an idea, but if the hardware random number generators use a jittery oscillator etc. Why not use [noise~] and [snapshot~] followed by some arithmetic and [int] you could build what I assume would be more random than the [random] box.
That's what is used for example in the "Can of Beats" scene for RjDj that still is a huge success with the listeners: http://rjdj.me/music/Chris%20McCormick/CanOfBeats/
Getting repeatable random numbers also has its use, though. For example in the EA/Maxis game "Spore" random numbers with repeated seeds are the base for a lot of the procedural music generated.
Ciao
Frank
Just an ignorant assumption, but would not the output of [noise~]
itself be generated from pseudo-random numbers? If not, then how does
[noise~] generate its randomness? Or is there something more complex
at work?
Ian
On 05/07/2009, at 7:12 PM, Andrew Faraday wrote:
Just an idea, but if the hardware random number generators use a
jittery oscillator etc. Why not use [noise~] and [snapshot~]
followed by some arithmetic and [int] you could build what I assume
would be more random than the [random] box.Andrew
Date: Sun, 5 Jul 2009 00:22:51 -0400 From: martin.peach@sympatico.ca To: mmoserbooth@gmail.com CC: pd-list@iem.at; zmoelnig@iem.at Subject: Re: [PD] help_random/seed
Mike Moser-Booth wrote:
IOhannes m zmölnig wrote:
Frank Barknecht wrote:
Hallo, cem guney hat gesagt: // cem guney wrote:
just started studying PD. going through the control examples
i've
been stuck trying to figure out the function of the message,
seed
123 in the example for "random". not sure if i figured out the
explanation below,
Seeds are kept locally so that if two Randoms are seeded the
same
they will have the same output (or indeed you can seed the
same one
twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is
cloudy there?
probably the simple fact, that [random] despite of it's name
does not
really produce random numbers. mostly when computers present you a "random" number, then this
number
will only appear to be random, but in reality is just
calculated as
the next item of a totally deterministic series. (as a matter of fact, a new random number is usually generated by simple taking the last number and then applying some more or less complicated transformation on this number). this method is
known as
"pseudo random".
you can set the "starting point" of the series by setting the
"seed",
which is the first number of the random sequence). since all
[random]
object use the same algorithm to calculate the next pseudo-random number, they will all end up with the same sequence if they all
start
with the same "seed". by default Pd uses different seeds for all [random] objects so
they
all appear to work independently.
In addition, it's probably worth mentioning that Pd will produce
the
same seeds for each [random] every time you load the patch. So
while
they appear to work independently, you will still get the same
results
each time you first run a patch after loading it.
A lot of the latest cpus have hardware random number generators that work by having a jittery oscillator sample the cpu clock, or
something
along those lines. (Such a jittery oscillator is assumed to have normally distributed transition times.) It would be nice if the random source could be independently
specified
for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite.
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Upgrade to Internet Explorer 8 Optimised for MSN. Download Now
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ian Andrews wrote:
Just an ignorant assumption, but would not the output of [noise~] itself be generated from pseudo-random numbers? If not, then how does [noise~] generate its randomness? Or is there something more complex at work?
Yes it's currently also a pseudo-random source. In fact it is this (from d_osc.c):
static t_int *noise_perform(t_int *w) { t_sample *out = (t_sample *)(w[1]); int *vp = (int *)(w[2]); int n = (int)(w[3]); int val = *vp; while (n--) { *out++ = ((float)((val & 0x7fffffff) - 0x40000000)) * (float)(1.0 / 0x40000000); val = val * 435898247 + 382842987; } *vp = val; return (w+4); }
...which is a deterministic chaos generator. But if you were to resample an oscillator that it's driving at a much lower rate then you would get more entropy, so it seems more random, but at the cost of losing a lot of samples.
Martin
Ian
On 05/07/2009, at 7:12 PM, Andrew Faraday wrote:
Just an idea, but if the hardware random number generators use a jittery oscillator etc. Why not use [noise~] and [snapshot~] followed by some arithmetic and [int] you could build what I assume would be more random than the [random] box.
Andrew
Date: Sun, 5 Jul 2009 00:22:51 -0400 From: martin.peach@sympatico.ca mailto:martin.peach@sympatico.ca To: mmoserbooth@gmail.com mailto:mmoserbooth@gmail.com CC: pd-list@iem.at mailto:pd-list@iem.at; zmoelnig@iem.at
Subject: Re: [PD] help_random/seed
Mike Moser-Booth wrote:
IOhannes m zmölnig wrote:
Frank Barknecht wrote:
Hallo, cem guney hat gesagt: // cem guney wrote:
> just started studying PD. going through the control examples i've > been stuck trying to figure out the function of the message, seed > 123 in the > example for "random". not sure if i figured out the explanation below, > > Seeds are kept locally so that if two Randoms are seeded the same > they will have the same output (or indeed you can seed the same one > twice to repeat the output.)
Yes, that's true, you understood correctly.
Oh, wait, that's what's in the help-file! What exactly is cloudy there?
probably the simple fact, that [random] despite of it's name does not really produce random numbers. mostly when computers present you a "random" number, then this number will only appear to be random, but in reality is just calculated as the next item of a totally deterministic series. (as a matter of fact, a new random number is usually generated by simple taking the last number and then applying some more or less complicated transformation on this number). this method is known as "pseudo random".
you can set the "starting point" of the series by setting the "seed", which is the first number of the random sequence). since all [random] object use the same algorithm to calculate the next pseudo-random number, they will all end up with the same sequence if they all start with the same "seed". by default Pd uses different seeds for all [random] objects so they all appear to work independently.
In addition, it's probably worth mentioning that Pd will produce the same seeds for each [random] every time you load the patch. So while they appear to work independently, you will still get the same results each time you first run a patch after loading it.
A lot of the latest cpus have hardware random number generators that work by having a jittery oscillator sample the cpu clock, or something along those lines. (Such a jittery oscillator is assumed to have normally distributed transition times.) It would be nice if the random source could be independently specified for all the pd objects that use random numbers, since the count of unreachable combinations when using the standard deterministic chaos generators is infinite.
Martin
Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Upgrade to Internet Explorer 8 Optimised for MSN. Download Now http://extras.uk.msn.com/internet-explorer-8/?ocid=T010MSN07A0716U _______________________________________________ Pd-list@iem.at mailto: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
Andrew Faraday wrote:
Just an idea, but if the hardware random number generators use a jittery oscillator etc. Why not use [noise~] and [snapshot~] followed by some arithmetic and [int] you could build what I assume would be more random than the [random] box.
weird idea. especially, since [noise~] uses exactly the same pseudo-random algorithm as [snapshot~].
now normal pseudo-random-number algorithms calculate integer pseudo-random numbers. (just like [random]. [noise~] has added a bit of extra work to convert this integer into a nice floating-point value. of course you could add some extra work to convert this float into an int again :-)
fgamrd IOhannes
IOhannes m zmoelnig wrote:
Andrew Faraday wrote:
Just an idea, but if the hardware random number generators use a jittery oscillator etc. Why not use [noise~] and [snapshot~] followed by some arithmetic and [int] you could build what I assume would be more random than the [random] box.
weird idea. especially, since [noise~] uses exactly the same pseudo-random algorithm as [snapshot~].
Snapshot~ outputs random numbers? That would explain a lot of oddities in my patches ;)
What does make sense is to use noise *from the adc* with snapshot~ to get seeds for your random objects, I think that was what Frank meant with the "Can of Beats" patch.
Cheers,
g.
Georg Bosch wrote:
IOhannes m zmoelnig wrote:
Andrew Faraday wrote:
Just an idea, but if the hardware random number generators use a jittery oscillator etc. Why not use [noise~] and [snapshot~] followed by some arithmetic and [int] you could build what I assume would be more random than the [random] box.
weird idea. especially, since [noise~] uses exactly the same pseudo-random algorithm as [snapshot~].
Snapshot~ outputs random numbers? That would explain a lot of oddities in my patches ;)
man, it was early in the morning....
What does make sense is to use noise *from the adc* with snapshot~ to get seeds for your random objects, I think that was what Frank meant with the "Can of Beats" patch.
yes that is a perfectly good idea (at least if you can make sure that the [adc~] will be hooked up to some real-world soundsource)
and then there is the wide range of time-based seeds (e.g. uptime of the computer, system time...)
gf asdrm IOhannes
I'm fairly sure that [snapshot~] doesn't generate random numbers, but marks the current point of an audio signal. Although this whole thing's got me thinking... If you use [snapshot~], attached to a real world sound source [adc~] to generate random numbers, then increasing volume would increase the range of your random generation. For instance [adc~]|[snapshot~] (plus a bang)|[+ 1]|[* 10]|[int]
In this case a sound source at a solid 1 - -1 volume (such as [osc~]) would give you a number from 0 to 20, when the bang is sent. but a quieter sound source e.g. 0.2 - -0.2 would provide a number from 0 - 4
Anyone fault my logic?
Date: Mon, 6 Jul 2009 11:37:35 +0200 From: zmoelnig@iem.at To: kram@stillavailable.com CC: pd-list@iem.at Subject: Re: [PD] help_random/seed
Georg Bosch wrote:
IOhannes m zmoelnig wrote:
Andrew Faraday wrote:
Just an idea, but if the hardware random number generators use a jittery oscillator etc. Why not use [noise~] and [snapshot~] followed by some arithmetic and [int] you could build what I assume would be more random than the [random] box.
weird idea. especially, since [noise~] uses exactly the same pseudo-random algorithm as [snapshot~].
Snapshot~ outputs random numbers? That would explain a lot of oddities in my patches ;)
man, it was early in the morning....
What does make sense is to use noise *from the adc* with snapshot~ to get seeds for your random objects, I think that was what Frank meant with the "Can of Beats" patch.
yes that is a perfectly good idea (at least if you can make sure that the [adc~] will be hooked up to some real-world soundsource)
and then there is the wide range of time-based seeds (e.g. uptime of the computer, system time...)
gf asdrm IOhannes
With Windows Live, you can organise, edit, and share your photos. http://clk.atdmt.com/UKM/go/134665338/direct/01/
Andrew Faraday wrote:
I'm fairly sure that [snapshot~] doesn't generate random numbers, but marks the current point of an audio signal.
indeed
Although this whole thing's got me thinking... If you use [snapshot~], attached to a real world sound source [adc~] to generate random numbers, then increasing volume would increase the range of your random generation. For instance [adc~]|[snapshot~] (plus a bang)|[+ 1]|[* 10]|[int]
first of all: [adc~] is _not_ a random number generator. it is an interface to the outside world. whatever is attached to your soundcard (or whatever feeds [adc~] will determine what comes out of [snapshot~].
e.g. if i connect [adc~] to [dac~] then i might hear whatever is recorded by my built-in microphone. i would not consider this "noise" in the strict mathematical sense.
if you connect an analog noise generator to your soundcard, then you might get a nice (and truely random, though coloured) noise.
now a real-world analog-digital converter always produces a (hopefully small) bit of thermal nose, which can be used as either a noise-source by itself (but take care, if you speak into the microphone...) or as a truely-random seed generator for a pseudo-random number generator.
the latter might give more what you would expect.
the former has (apart from the "microphone" problem) the drawback, that it will only generate a single "random" number per audio-block (or to be precise: 64 for of them); which might be just too few for your application...
In this case a sound source at a solid 1 - -1 volume (such as [osc~]) would give you a number from 0 to 20, when the bang is sent. but a quieter sound source e.g. 0.2 - -0.2 would provide a number from 0 - 4
Anyone fault my logic?
simple primary school mathematics? ([-1..1] + 1)*10 = [0..2]*10 = [0..20] ([-0.2..0.2] + 1)*10 = [0.8..1.2]*10 = [8..12]
fmgasdr IOhannes
Maybe this may be of interest:
http://www.random.org/sounds/description/
Kind regards, Loerenzo
IOhannes m zmoelnig wrote:
Andrew Faraday wrote:
I'm fairly sure that [snapshot~] doesn't generate random numbers, but marks the current point of an audio signal.
indeed
Although this whole thing's got me thinking... If you use [snapshot~], attached to a real world sound source [adc~] to generate random numbers, then increasing volume would increase the range of your random generation. For instance [adc~]|[snapshot~] (plus a bang)|[+ 1]|[* 10]|[int]
first of all: [adc~] is _not_ a random number generator. it is an interface to the outside world. whatever is attached to your soundcard (or whatever feeds [adc~] will determine what comes out of [snapshot~].
e.g. if i connect [adc~] to [dac~] then i might hear whatever is recorded by my built-in microphone. i would not consider this "noise" in the strict mathematical sense.
if you connect an analog noise generator to your soundcard, then you might get a nice (and truely random, though coloured) noise.
now a real-world analog-digital converter always produces a (hopefully small) bit of thermal nose, which can be used as either a noise-source by itself (but take care, if you speak into the microphone...) or as a truely-random seed generator for a pseudo-random number generator.
the latter might give more what you would expect.
the former has (apart from the "microphone" problem) the drawback, that it will only generate a single "random" number per audio-block (or to be precise: 64 for of them); which might be just too few for your application...
In this case a sound source at a solid 1 - -1 volume (such as [osc~]) would give you a number from 0 to 20, when the bang is sent. but a quieter sound source e.g. 0.2 - -0.2 would provide a number from 0 - 4
Anyone fault my logic?
simple primary school mathematics? ([-1..1] + 1)*10 = [0..2]*10 = [0..20] ([-0.2..0.2] + 1)*10 = [0.8..1.2]*10 = [8..12]
fmgasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hello, i m looking for projects written in pd (or max) with space as a main subject... like lemma 1 and 2 from the global-visual-music-project (puckette). thanks.
http://redirect.gimas.net/?n=M0906xWLHM2 Unbegrenzter Speicher bei Windows Live Hotmail!
-
Andrew Faraday -
cem guney -
Frank Barknecht -
Georg Bosch -
Ian Andrews -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Lorenzo -
Martin Peach -
Mike Moser-Booth -
steffen scholl