Re: [PD] [random] and seed value

[Julian Brooks]

Thx for fix & additional info IOhannes - not too shabby then...



--- Original Message ---
On Thursday, December 15th, 2022 at 11:23, IOhannes m zmoelnig 
 wrote:


> 
> 
> On 12/14/22 23:55, Julian Brooks wrote:
> 
> > Yes, I'm one of those...
> 
> 
> then i think you should start setting an explicit seed right now.
> 
> the simplest way i've found to force the currently hardcoded seed (for
> the first instantiated random generater), is something like this:
> 
> 1. seed the random generator with 255406
> 2. discard the first 3186 random numbers
> 
> like so:
> #N canvas 2082 640 533 344 12;
> #X msg 307 69 seed 255406;
> #X msg 327 123 3186;
> #X obj 327 148 until;
> #X obj 230 246 spigot;
> #X msg 307 174 1;
> #X obj 230 271 print;
> #X msg 202 166 bang;
> #X obj 307 94 t b b a b;
> #X msg 367 172 0;
> #X obj 230 221 random 100;
> #X obj 281 197 t a;
> #X obj 367 200 t f;
> #X text 311 45 reset;
> #X connect 0 0 7 0;
> #X connect 1 0 2 0;
> #X connect 2 0 10 0;
> #X connect 3 0 5 0;
> #X connect 4 0 11 0;
> #X connect 6 0 9 0;
> #X connect 7 0 4 0;
> #X connect 7 1 1 0;
> #X connect 7 2 10 0;
> #X connect 7 3 8 0;
> #X connect 8 0 11 0;
> #X connect 9 0 3 0;
> #X connect 10 0 9 0;
> #X connect 11 0 3 1;
> 
> > [random] seems to rear its head now & then.
> 
> 
> of course it loops. it's a pseudo random generator.
> however, i find that the underlying algorithm is somewhat perfect with
> regard to repetition (last time i checked, it required about 4294967295
> iterations to repeat, which is pretty good for a 32bit integer number).
> 
> that's not to say that the distribution for small ranges as output by
> [random] might not be ideal.
> 
> > My memory is that when asked on here, Miller was a little coy about the 
> > algo (when was highlighted on-list as an 'interesting' [non-standard] 
> > implementation:)
> 
> 
> iirc, miller always claimed that he was just blindly hitting the number
> keys to generate large numbers.
> 
> i don't fully trust this statement for the actual random generator
> (given that it consumes all possible numbers before repeating), but for
> the seed generator this is somewhat plausible, as this one only takes
> 536870912 iterations to repeat itself (so the PRNG itself has an 8-times
> longer period)
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[IOhannes m zmoelnig]

On 12/14/22 23:55, Julian Brooks wrote:


Yes, I'm one of those...


then i think you should start setting an explicit seed right now.

the simplest way i've found to force the currently hardcoded seed (for 
the first instantiated random generater), is something like this:


1. seed the random generator with 255406
2. discard the first 3186 random numbers

like so:
#N canvas 2082 640 533 344 12;
#X msg 307 69 seed 255406;
#X msg 327 123 3186;
#X obj 327 148 until;
#X obj 230 246 spigot;
#X msg 307 174 1;
#X obj 230 271 print;
#X msg 202 166 bang;
#X obj 307 94 t b b a b;
#X msg 367 172 0;
#X obj 230 221 random 100;
#X obj 281 197 t a;
#X obj 367 200 t f;
#X text 311 45 reset;
#X connect 0 0 7 0;
#X connect 1 0 2 0;
#X connect 2 0 10 0;
#X connect 3 0 5 0;
#X connect 4 0 11 0;
#X connect 6 0 9 0;
#X connect 7 0 4 0;
#X connect 7 1 1 0;
#X connect 7 2 10 0;
#X connect 7 3 8 0;
#X connect 8 0 11 0;
#X connect 9 0 3 0;
#X connect 10 0 9 0;
#X connect 11 0 3 1;


[random] seems to rear its head now & then.


of course it loops. it's a pseudo random generator.
however, i find that the underlying algorithm is somewhat perfect with 
regard to repetition (last time i checked, it required about 4294967295 
iterations to repeat, which is pretty good for a 32bit integer number).


that's not to say that the distribution for small ranges as output by 
[random] might *not* be ideal.



My memory is that when asked on here, Miller was a little coy about the algo 
(when was highlighted on-list as an 'interesting' [non-standard] 
implementation:)


iirc, miller always claimed that he was just blindly hitting the number 
keys to generate large numbers.


i don't fully trust this statement for the actual random generator 
(given that it consumes all possible numbers before repeating), but for 
the seed generator this is somewhat plausible, as this one only takes 
536870912 iterations to repeat itself (so the PRNG itself has an 8-times 
longer period)


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Julian Brooks]

"there are definitely pieces out there where
the composer expects the "random" piece to sound like "that", and which
will no longer be true if [random] uses different seeds for each instance)."

Yes, I'm one of those...

[random] seems to rear its head now & then.
My memory is that when asked on here, Miller was a little coy about the algo 
(when was highlighted on-list as an 'interesting' [non-standard] 
implementation:)

Seasons greets
J


--- Original Message ---
On Sunday, December 11th, 2022 at 15:55, Thomas Mayer  
wrote:


> 
> 
> Hello,
> 
> currently [random] uses a fixed value for initialisation. This leads to
> the same sequence of values all the time.
> 
> https://github.com/pure-data/pure-data/blob/c0cd34924a50bdd1cc37dfb6b01f9be02ad8a78b/src/x_misc.c#L55
> 
> My guess is, that most users probably expect at least different seed
> values every time.
> 
> Maybe the help file should explicitely state the behaviour or a
> different way for deriving the initial seed should be used, e.g. taking
> the local time. Or a better PRNG could be used as well.
> 
> If we take the solution to initialize [random] with a different seed
> each time, an explanation on how to revert to the old behaviour of a
> seed value of 1489853723 should be mentioned in the help.
> 
> I could tackle that, but would like a discussion about that before coding.
> 
> Thanks,
> Thomas
> --
> "Prisons are needed only to provide the illusion that courts and police
> are effective. They're a kind of job insurance."
> (Leto II. in: Frank Herbert, God Emperor of Dune)
> http://www.residuum.org/
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Philip Stone via Pd-list]

Hello all,

I don’t think anybody is advocating for this, but I just wanted to be sure that 
whatever changes are made to [random], the ‘seed’ message capability is 
maintained. My music very much depends on the ability to control the seed value 
and get a repeatable ‘random’ sequence.

Where I need a truly random seed, I loadbang a [timer], and then have an ‘Init’ 
button that initializes all of my system. At that point, I use the value from 
the timer to seed [random].


Best,

Phil Stone
Davis, CA. USA
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Alexandre Torres Porres]

The fact that you don't get different seeds is arguably something to
mention in the help files.

One thing is that this is not a real feature as I see it, because you can't
really control the number of [random] objects that were created before
opening a particular patch.

On the other hand, I can't believe people do rely on a [random] object
giving the same output every time you open the patch. We have it in the
documentation that using 'seed' is what you need for this and this is the
only thing that can actually be done to guarantee the same sequence.

You can use externals like zexy's (ELSE also has [datetime] because someone
requested) but if yo're gonna have to use externals, you might just end up
using an external for a random number generator that has this function
built in it already, and ALL random/noise generators in ELSE do this.

Now, I believe Pd Vanilla's random number generators should have an actual
unpredictable seed and I already have a PR for this, see -->
https://github.com/pure-data/pure-data/pull/1719

I don't think this will break anything but worst case scenario, we can have
those 'compatibilty flags' IOhaness is not much a fan of :)

Vanilla could also have something like [date]/[time] one way or another,
but adding it just for the case of managing seeds in [random] seems like a
bad idea to me.

cheers

Em dom., 11 de dez. de 2022 às 21:37, Thomas Mayer 
escreveu:

> On 11.12.22 23:22, Peter P. wrote:
> > Hi Thomas,
> >
> > * Thomas Mayer  [2022-12-11 21:20]:
> > [...]
> >> My guess is, that most users probably expect at least different seed
> values
> >> every time.
> >>
> >> Maybe the help file should explicitely state the behaviour or a
> different
> >> way for deriving the initial seed should be used, e.g. taking the local
> >> time. Or a better PRNG could be used as well.
> >>
> >> If we take the solution to initialize [random] with a different seed
> each
> >> time, an explanation on how to revert to the old behaviour of a seed
> value
> >> of 1489853723 should be mentioned in the help.
> > I think the main thing to worry about is if any of the patches written
> > in the last 20+ years will stop working in the way intended by a such a
> > modification.
> >
> > I loosely remember that someone somewhen showed how to get a different
> > seed every time using an abstraction. If such a solution exists in
> > vanilla Pd, it could be added as a solution to the docs perhaps?
>
> if backwards-compatibility is the main factor, then I will create a pull
> request with an update to the help file and explain a way to generate a
> good seed value with Pd vanilla, where I actually do not have a good
> idea for now, because I am using [time] from zexy right now.
>
> Thanks,
> Thomas
> --
> "It seems to me, Golan, that the advance of civilization is nothing
> but an exercise in the limiting of privacy."
> (Janov Pelorat in: Isaac Asimov - Foundation's Edge)
> http://www.residuum.org/
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Thomas Mayer]

On 11.12.22 23:22, Peter P. wrote:

Hi Thomas,

* Thomas Mayer  [2022-12-11 21:20]:
[...]

My guess is, that most users probably expect at least different seed values
every time.

Maybe the help file should explicitely state the behaviour or a different
way for deriving the initial seed should be used, e.g. taking the local
time. Or a better PRNG could be used as well.

If we take the solution to initialize [random] with a different seed each
time, an explanation on how to revert to the old behaviour of a seed value
of 1489853723 should be mentioned in the help.

I think the main thing to worry about is if any of the patches written
in the last 20+ years will stop working in the way intended by a such a
modification.

I loosely remember that someone somewhen showed how to get a different
seed every time using an abstraction. If such a solution exists in
vanilla Pd, it could be added as a solution to the docs perhaps?


if backwards-compatibility is the main factor, then I will create a pull 
request with an update to the help file and explain a way to generate a 
good seed value with Pd vanilla, where I actually do not have a good 
idea for now, because I am using [time] from zexy right now.


Thanks,
Thomas
--
"It seems to me, Golan, that the advance of civilization is nothing
but an exercise in the limiting of privacy."
(Janov Pelorat in: Isaac Asimov - Foundation's Edge)
http://www.residuum.org/




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Dan Wilcox]

> On Dec 11, 2022, at 11:58 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 2
> Date: Sun, 11 Dec 2022 22:34:14 + (UTC)
> From: Sebastian Shader mailto:sebfumas...@aol.com>>
> ...
> of course the most common suggestion is to use [date] and [time] from zexy. 
> maybe the better solution is to put those objects into vanilla..

+1 in any case. [date] and [time] are among a few of the last objects I'd need 
in vanilla on iOS.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Sebastian Shader via Pd-list]

well it used to be the case that it was difficult to save per-abstraction 
parameters. with the addition of [savestate]I don't think that's as much of a 
factor anymore.

 In the past you could have a simple abstraction that could increment a value 
held in a message box to supply a different seed everytime a patch was loaded.
But now you could do basically the same with [savestate] I think. (and don't 
have to store save state outside the abstraction yourself)
of course the most common suggestion is to use [date] and [time] from zexy. 
maybe the better solution is to put those objects into vanilla..
 because such an abstraction would be very simple also.

-seb
-Original Message-
From: Peter P. 
To: pd-list@lists.iem.at
Sent: Sun, Dec 11, 2022 2:22 pm
Subject: Re: [PD] [random] and seed value

Hi Thomas,

* Thomas Mayer  [2022-12-11 21:20]:
[...]
> My guess is, that most users probably expect at least different seed values
> every time.
> 
> Maybe the help file should explicitely state the behaviour or a different
> way for deriving the initial seed should be used, e.g. taking the local
> time. Or a better PRNG could be used as well.
> 
> If we take the solution to initialize [random] with a different seed each
> time, an explanation on how to revert to the old behaviour of a seed value
> of 1489853723 should be mentioned in the help.
I think the main thing to worry about is if any of the patches written
in the last 20+ years will stop working in the way intended by a such a
modification.

I loosely remember that someone somewhen showed how to get a different
seed every time using an abstraction. If such a solution exists in
vanilla Pd, it could be added as a solution to the docs perhaps?



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Peter P.]

Hi Thomas,

* Thomas Mayer  [2022-12-11 21:20]:
[...]
> My guess is, that most users probably expect at least different seed values
> every time.
> 
> Maybe the help file should explicitely state the behaviour or a different
> way for deriving the initial seed should be used, e.g. taking the local
> time. Or a better PRNG could be used as well.
> 
> If we take the solution to initialize [random] with a different seed each
> time, an explanation on how to revert to the old behaviour of a seed value
> of 1489853723 should be mentioned in the help.
I think the main thing to worry about is if any of the patches written
in the last 20+ years will stop working in the way intended by a such a
modification.

I loosely remember that someone somewhen showed how to get a different
seed every time using an abstraction. If such a solution exists in
vanilla Pd, it could be added as a solution to the docs perhaps?



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[Dan Wilcox]

Related: https://github.com/pure-data/pure-data/issues/1717 
<https://github.com/pure-data/pure-data/issues/1717>

> On Dec 11, 2022, at 9:59 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 2
> Date: Sun, 11 Dec 2022 16:55:40 +0100
> From: Thomas Mayer mailto:tho...@residuum.org>>
> To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
> Subject: [PD] [random] and seed value
> Message-ID: <478be1b4-8f1c-ee0f-d11c-889b51371...@residuum.org 
> <mailto:478be1b4-8f1c-ee0f-d11c-889b51371...@residuum.org>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Hello,
> 
> currently [random] uses a fixed value for initialisation. This leads to 
> the same sequence of values all the time.
> 
> https://github.com/pure-data/pure-data/blob/c0cd34924a50bdd1cc37dfb6b01f9be02ad8a78b/src/x_misc.c#L55
>  
> <https://github.com/pure-data/pure-data/blob/c0cd34924a50bdd1cc37dfb6b01f9be02ad8a78b/src/x_misc.c#L55>
> 
> My guess is, that most users probably expect at least different seed 
> values every time.
> 
> Maybe the help file should explicitely state the behaviour or a 
> different way for deriving the initial seed should be used, e.g. taking 
> the local time. Or a better PRNG could be used as well.
> 
> If we take the solution to initialize [random] with a different seed 
> each time, an explanation on how to revert to the old behaviour of a 
> seed value of 1489853723 should be mentioned in the help.
> 
> I could tackle that, but would like a discussion about that before coding.
> 
> Thanks,
> Thomas
> -- 


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [random] and seed value

[Thomas Mayer]

Hello,

currently [random] uses a fixed value for initialisation. This leads to 
the same sequence of values all the time.


https://github.com/pure-data/pure-data/blob/c0cd34924a50bdd1cc37dfb6b01f9be02ad8a78b/src/x_misc.c#L55

My guess is, that most users probably expect at least different seed 
values every time.


Maybe the help file should explicitely state the behaviour or a 
different way for deriving the initial seed should be used, e.g. taking 
the local time. Or a better PRNG could be used as well.


If we take the solution to initialize [random] with a different seed 
each time, an explanation on how to revert to the old behaviour of a 
seed value of 1489853723 should be mentioned in the help.


I could tackle that, but would like a discussion about that before coding.

Thanks,
Thomas
--
"Prisons are needed only to provide the illusion that courts and police
are effective. They're a kind of job insurance."
(Leto II. in: Frank Herbert, God Emperor of Dune)
http://www.residuum.org/



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] random routing of 8 audio-streams to 8 outputs

[hans w. koch]

(to keep me from what i am supposed to do :-)

here is a solution for 3 channels, easily expandable - vanilla only.
it uses c_urn from PdParty_composerpack/lib/rj
which i attach as convenience

hth
hans



randomize_loudspeakers.pd
Description: Binary data


c_urn-help.pd
Description: Binary data


c_urn.pd
Description: Binary data



> Am 05.10.2021 um 00:08 schrieb Simon Iten :
> 
> 
> 
> 
> is there a somewhat elegant way to route 8 audio outputs (from readsf~) to 8 
> dac~ outputs randomly (on a bang for example)?
> 
> i.e. out1 to dac4, out2 to dac7 etc.
> 
> each output is allowed to one dac~ channel only.
> 
> mathematically speaking that would be 8! 8x7x6x5x4x3x2x1 (40320) 
> possibilites, but i don’t see an easy way to program this in puredata.
> 
> some way of dynamic patching maybe? or a throw~ and catch~ approach? i get 
> stuck on the random logic, since every “step” that chooses a destinations 
> changes the subsequent outputs that are still allowed to be chosen.
> 
> 
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Liam Goodacre]

Each new instance of [random] already seeds itself differently, so adding $0 
isn't going to change anything there. The problem is that the seeds are 
repeated when you restart PD, so you'll get the same pseudo-random results 
every time you open the program. $0 won't help here, because the $0 values also 
repeat when you restart PD.

From: Pd-list  on behalf of Peter P. 

Sent: 02 July 2018 18:26
To: pd-list@lists.iem.at
Subject: Re: [PD] Random

* Liam Goodacre  [2018-07-02 06:34]:
> Perhaps using $0 might be better then as it is unique and automatically
> assigned.
>
> But $0 itself is deterministic--the first instance is 1003, the second is 
> 1004, etc.
Yes, but it will provide a different seed to [random] inside every
abstraction. Forgive me if I understand your intentions in the wrong
way-

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Peter P.]

* Liam Goodacre  [2018-07-02 06:34]:
> Perhaps using $0 might be better then as it is unique and automatically
> assigned.
> 
> But $0 itself is deterministic--the first instance is 1003, the second is 
> 1004, etc.
Yes, but it will provide a different seed to [random] inside every
abstraction. Forgive me if I understand your intentions in the wrong
way-

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Peter P.]

* Fede Camara Halac  [2018-06-30 19:51]:
> Hello,
> 
> I find it useful to wrap random in an abstraction, so that I use $2 as an 
> instance id, to both receive a "seed" and to add the abstraction id to the 
> seed.
Perhaps using $0 might be better then as it is unique and automatically
assigned.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Fede Camara Halac]

> 
> a) it's super-easy to implement as an abstraction. what would a built-in
> solution give you that an abstraction cannot give you?
well, I think it would guarantee that there is uniqueness on each random 
object, independently on pd instances ideally

> b) it adds a false sense of randomness.
> either the seed should be stupid enough (as is now), or it should have
> proper entropy. your solution is inbetween.

I agree, yes. Proper entropy or something close to that would mean a proper 
solution. I just want to be practical and efficient with what we have

Cheers!

f
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[IOhannes m zmölnig]

On 06/30/2018 07:51 PM, Fede Camara Halac wrote:
> Hello,
> 
> I find it useful to wrap random in an abstraction, so that I use $2 as an 
> instance id, to both receive a "seed" and to add the abstraction id to the 
> seed.
> 
> But, it would be really useful to have a unique instance id already generated 
> in the [random] object, and a global symbol to bind all [random]s to send a 
> seed and increment it by each unique id. 
> 
> what do you think? is this possible?

i think it is possible, and i don't think it should be implemented.
a) it's super-easy to implement as an abstraction. what would a built-in
solution give you that an abstraction cannot give you?
b) it adds a false sense of randomness.
either the seed should be stupid enough (as is now), or it should have
proper entropy. your solution is inbetween.

gfmsadf
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Fede Camara Halac]

Hello,

I find it useful to wrap random in an abstraction, so that I use $2 as an 
instance id, to both receive a "seed" and to add the abstraction id to the seed.

But, it would be really useful to have a unique instance id already generated 
in the [random] object, and a global symbol to bind all [random]s to send a 
seed and increment it by each unique id. 

what do you think? is this possible?

I tested briefly and thie wrapping method really gives different random streams 
provided there is a different seed when opening the patch

cheers,

fede

> On May 31, 2018, at 10:00 PM, Martin Peach  wrote:
> 
>> On Thu, May 31, 2018 at 3:09 PM, hans w. koch  wrote:
>> but couldn´t that pi limitation worked around by a loadbang -delay combo to 
>> read a date, once the system has established one?
>> would need mention in the helpfile though.
>> 
> The pi might not be connected to any network, in which case it will always 
> start at Jan 1, 2000.
> /dev/random may not be usable right at startup as it needs time to accumulate 
> entropy, .dev/urandom is guaranteed to give some sort of random. Reading a 
> few bytes from /dev/urandom into a table then combining them into a float or 
> long int seems like a better idea.
> There's an equivalent method in the WIndows API (SystemPrng), but it would 
> have to be coded into an external since it's not a file like in linux.
> 
> Martin
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Martin Peach]

On Thu, May 31, 2018 at 3:09 PM, hans w. koch  wrote:

> but couldn´t that pi limitation worked around by a loadbang -delay combo
> to read a date, once the system has established one?
> would need mention in the helpfile though.
>
> The pi might not be connected to any network, in which case it will always
start at Jan 1, 2000.
/dev/random may not be usable right at startup as it needs time to
accumulate entropy, .dev/urandom is guaranteed to give some sort of random.
Reading a few bytes from /dev/urandom into a table then combining them into
a float or long int seems like a better idea.
There's an equivalent method in the WIndows API (SystemPrng), but it would
have to be coded into an external since it's not a file like in linux.

Martin
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[hans w. koch]

but couldn´t that pi limitation worked around by a loadbang -delay combo to 
read a date, once the system has established one?
would need mention in the helpfile though.

currently i use [shell] to read a date/hour into pd. 
it works well (e.g. in an installation, where i cue this every second, running 
since mid march), but always wondered, why there was no native way.
time stamped filenames would be another good use, among many others.
i even made a donation once, to have this in mobmuplat.

cheers
hans


> Am 31.05.2018 um 20:20 schrieb Dan Wilcox :
> 
> Ok, makes sense. A [date] object would still be useful for my case: 
> generating filenames with timestamps. :)
> 
> That's why I was thinking of some sort of [seed] or [salt] object which would 
> wrap reading from a default pseudo-random source such as /dev/random or some 
> system equivalent.
> 
>> On May 31, 2018, at 1:16 PM, Miller Puckette  wrote:
>> 
>> The Pi always boots at a constant date (no battery to keep a clock running).
>> 
>> cheers
>> M
>> On Thu, May 31, 2018 at 01:14:08PM -0500, Dan Wilcox wrote:
>>> I was thinking it would just return the posix date via outlets or a list. 
>>> Why would Pd need to save the previous date?
>>> 
 On May 31, 2018, at 1:11 PM, Miller Puckette  wrote:
 
 Warning:  [date] won't work so well on Raspberry Pi startup scripts (no
 way to save date from boot to boot).
 
 I think the best vanilla way on linux or mac is to read /dev/random into
 an array using soundfiler.
 
 cheers
 Miller
 
 On Thu, May 31, 2018 at 01:00:40PM -0500, Dan Wilcox wrote:
> Yeah. I could use it as [date] is the only reason I have zexy installed 
> right now.
> 
>> On May 31, 2018, at 12:56 PM, hans w. koch  wrote:
>> 
>> wouldn´t it be more interesting/useful to incorporate a [date] object 
>> into vanilla pd, from which it would be trivial to generate unique 
>> seeds, but which also could be used in (many) other contexts?
>> 
>> hans
>> 
>> 
>>> Am 31.05.2018 um 19:21 schrieb Dan Wilcox :
>>> 
>>> It would relatively easy to add a right outlet to [random]. Another 
>>> option might be an explicit [seed] object which could give you further 
>>> control or perhaps some creation flags for [random] as well.
>>> 
> you still have control on the seed... just seed it
 
 no because you need to add an extra outlet to [random] and prints out 
 the
 seed value.
 
> or even seed it with the system time on creation?
 
 if one adds now this behaviour one need to put a flag for backward
 compatibility.
 
> what if [seed( without argument would take the current system time?
 
 this could be an idea but one need the second outlet.
 
 ciao
 -Marco Matteo Markidis
>>> 
>>> 
>>> Dan Wilcox
>>> @danomatika
>>> danomatika.com
>>> robotcowboy.com
>>> 
>>> 
>>> 
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> https://lists.puredata.info/listinfo/pd-list
>> 
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 
 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
 
>>> 
>>> 
>>> Dan Wilcox
>>> @danomatika 
>>> danomatika.com 
>>> robotcowboy.com 
>>> 
>>> 
>>> 
>> 
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> https://lists.puredata.info/listinfo/pd-list
> 
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Dan Wilcox]

Ok, makes sense. A [date] object would still be useful for my case: generating 
filenames with timestamps. :)

That's why I was thinking of some sort of [seed] or [salt] object which would 
wrap reading from a default pseudo-random source such as /dev/random or some 
system equivalent.

> On May 31, 2018, at 1:16 PM, Miller Puckette  wrote:
> 
> The Pi always boots at a constant date (no battery to keep a clock running).
> 
> cheers
> M
> On Thu, May 31, 2018 at 01:14:08PM -0500, Dan Wilcox wrote:
>> I was thinking it would just return the posix date via outlets or a list. 
>> Why would Pd need to save the previous date?
>> 
>>> On May 31, 2018, at 1:11 PM, Miller Puckette  wrote:
>>> 
>>> Warning:  [date] won't work so well on Raspberry Pi startup scripts (no
>>> way to save date from boot to boot).
>>> 
>>> I think the best vanilla way on linux or mac is to read /dev/random into
>>> an array using soundfiler.
>>> 
>>> cheers
>>> Miller
>>> 
>>> On Thu, May 31, 2018 at 01:00:40PM -0500, Dan Wilcox wrote:
 Yeah. I could use it as [date] is the only reason I have zexy installed 
 right now.
 
> On May 31, 2018, at 12:56 PM, hans w. koch  wrote:
> 
> wouldn´t it be more interesting/useful to incorporate a [date] object 
> into vanilla pd, from which it would be trivial to generate unique seeds, 
> but which also could be used in (many) other contexts?
> 
> hans
> 
> 
>> Am 31.05.2018 um 19:21 schrieb Dan Wilcox :
>> 
>> It would relatively easy to add a right outlet to [random]. Another 
>> option might be an explicit [seed] object which could give you further 
>> control or perhaps some creation flags for [random] as well.
>> 
 you still have control on the seed... just seed it
>>> 
>>> no because you need to add an extra outlet to [random] and prints out 
>>> the
>>> seed value.
>>> 
 or even seed it with the system time on creation?
>>> 
>>> if one adds now this behaviour one need to put a flag for backward
>>> compatibility.
>>> 
 what if [seed( without argument would take the current system time?
>>> 
>>> this could be an idea but one need the second outlet.
>>> 
>>> ciao
>>> -Marco Matteo Markidis
>> 
>> 
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>> 
>> 
>> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 
 
 
 Dan Wilcox
 @danomatika 
 danomatika.com 
 robotcowboy.com 
 
 
 
>>> 
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> 
 https://lists.puredata.info/listinfo/pd-list
>>> 
>> 
>> 
>> Dan Wilcox
>> @danomatika >
>> danomatika.com  > >
>> robotcowboy.com  > >
>> 
>> 
>> 
> 
>> ___
>> Pd-list@lists.iem.at  mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list 
>> 

Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Miller Puckette]

The Pi always boots at a constant date (no battery to keep a clock running).

cheers
M
On Thu, May 31, 2018 at 01:14:08PM -0500, Dan Wilcox wrote:
> I was thinking it would just return the posix date via outlets or a list. Why 
> would Pd need to save the previous date?
> 
> > On May 31, 2018, at 1:11 PM, Miller Puckette  wrote:
> > 
> > Warning:  [date] won't work so well on Raspberry Pi startup scripts (no
> > way to save date from boot to boot).
> > 
> > I think the best vanilla way on linux or mac is to read /dev/random into
> > an array using soundfiler.
> > 
> > cheers
> > Miller
> > 
> > On Thu, May 31, 2018 at 01:00:40PM -0500, Dan Wilcox wrote:
> >> Yeah. I could use it as [date] is the only reason I have zexy installed 
> >> right now.
> >> 
> >>> On May 31, 2018, at 12:56 PM, hans w. koch  wrote:
> >>> 
> >>> wouldn´t it be more interesting/useful to incorporate a [date] object 
> >>> into vanilla pd, from which it would be trivial to generate unique seeds, 
> >>> but which also could be used in (many) other contexts?
> >>> 
> >>> hans
> >>> 
> >>> 
>  Am 31.05.2018 um 19:21 schrieb Dan Wilcox :
>  
>  It would relatively easy to add a right outlet to [random]. Another 
>  option might be an explicit [seed] object which could give you further 
>  control or perhaps some creation flags for [random] as well.
>  
> >> you still have control on the seed... just seed it
> > 
> > no because you need to add an extra outlet to [random] and prints out 
> > the
> > seed value.
> > 
> >> or even seed it with the system time on creation?
> > 
> > if one adds now this behaviour one need to put a flag for backward
> > compatibility.
> > 
> >> what if [seed( without argument would take the current system time?
> > 
> > this could be an idea but one need the second outlet.
> > 
> > ciao
> > -Marco Matteo Markidis
>  
>  
>  Dan Wilcox
>  @danomatika
>  danomatika.com
>  robotcowboy.com
>  
>  
>  
>  ___
>  Pd-list@lists.iem.at mailing list
>  UNSUBSCRIBE and account-management -> 
>  https://lists.puredata.info/listinfo/pd-list
> >>> 
> >> 
> >> 
> >> Dan Wilcox
> >> @danomatika 
> >> danomatika.com 
> >> robotcowboy.com 
> >> 
> >> 
> >> 
> > 
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> > 
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Dan Wilcox]

I was thinking it would just return the posix date via outlets or a list. Why 
would Pd need to save the previous date?

> On May 31, 2018, at 1:11 PM, Miller Puckette  wrote:
> 
> Warning:  [date] won't work so well on Raspberry Pi startup scripts (no
> way to save date from boot to boot).
> 
> I think the best vanilla way on linux or mac is to read /dev/random into
> an array using soundfiler.
> 
> cheers
> Miller
> 
> On Thu, May 31, 2018 at 01:00:40PM -0500, Dan Wilcox wrote:
>> Yeah. I could use it as [date] is the only reason I have zexy installed 
>> right now.
>> 
>>> On May 31, 2018, at 12:56 PM, hans w. koch  wrote:
>>> 
>>> wouldn´t it be more interesting/useful to incorporate a [date] object into 
>>> vanilla pd, from which it would be trivial to generate unique seeds, but 
>>> which also could be used in (many) other contexts?
>>> 
>>> hans
>>> 
>>> 
 Am 31.05.2018 um 19:21 schrieb Dan Wilcox :
 
 It would relatively easy to add a right outlet to [random]. Another option 
 might be an explicit [seed] object which could give you further control or 
 perhaps some creation flags for [random] as well.
 
>> you still have control on the seed... just seed it
> 
> no because you need to add an extra outlet to [random] and prints out the
> seed value.
> 
>> or even seed it with the system time on creation?
> 
> if one adds now this behaviour one need to put a flag for backward
> compatibility.
> 
>> what if [seed( without argument would take the current system time?
> 
> this could be an idea but one need the second outlet.
> 
> ciao
> -Marco Matteo Markidis
 
 
 Dan Wilcox
 @danomatika
 danomatika.com
 robotcowboy.com
 
 
 
 ___
 Pd-list@lists.iem.at mailing list
 UNSUBSCRIBE and account-management -> 
 https://lists.puredata.info/listinfo/pd-list
>>> 
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>> 
>> 
>> 
> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Miller Puckette]

Warning:  [date] won't work so well on Raspberry Pi startup scripts (no
way to save date from boot to boot).

I think the best vanilla way on linux or mac is to read /dev/random into
an array using soundfiler.

cheers
Miller

On Thu, May 31, 2018 at 01:00:40PM -0500, Dan Wilcox wrote:
> Yeah. I could use it as [date] is the only reason I have zexy installed right 
> now.
> 
> > On May 31, 2018, at 12:56 PM, hans w. koch  wrote:
> > 
> > wouldn´t it be more interesting/useful to incorporate a [date] object into 
> > vanilla pd, from which it would be trivial to generate unique seeds, but 
> > which also could be used in (many) other contexts?
> > 
> > hans
> > 
> > 
> >> Am 31.05.2018 um 19:21 schrieb Dan Wilcox :
> >> 
> >> It would relatively easy to add a right outlet to [random]. Another option 
> >> might be an explicit [seed] object which could give you further control or 
> >> perhaps some creation flags for [random] as well.
> >> 
>  you still have control on the seed... just seed it
> >>> 
> >>> no because you need to add an extra outlet to [random] and prints out the
> >>> seed value.
> >>> 
>  or even seed it with the system time on creation?
> >>> 
> >>> if one adds now this behaviour one need to put a flag for backward
> >>> compatibility.
> >>> 
>  what if [seed( without argument would take the current system time?
> >>> 
> >>> this could be an idea but one need the second outlet.
> >>> 
> >>> ciao
> >>> -Marco Matteo Markidis
> >> 
> >> 
> >> Dan Wilcox
> >> @danomatika
> >> danomatika.com
> >> robotcowboy.com
> >> 
> >> 
> >> 
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> > 
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Dan Wilcox]

Yeah. I could use it as [date] is the only reason I have zexy installed right 
now.

> On May 31, 2018, at 12:56 PM, hans w. koch  wrote:
> 
> wouldn´t it be more interesting/useful to incorporate a [date] object into 
> vanilla pd, from which it would be trivial to generate unique seeds, but 
> which also could be used in (many) other contexts?
> 
> hans
> 
> 
>> Am 31.05.2018 um 19:21 schrieb Dan Wilcox :
>> 
>> It would relatively easy to add a right outlet to [random]. Another option 
>> might be an explicit [seed] object which could give you further control or 
>> perhaps some creation flags for [random] as well.
>> 
 you still have control on the seed... just seed it
>>> 
>>> no because you need to add an extra outlet to [random] and prints out the
>>> seed value.
>>> 
 or even seed it with the system time on creation?
>>> 
>>> if one adds now this behaviour one need to put a flag for backward
>>> compatibility.
>>> 
 what if [seed( without argument would take the current system time?
>>> 
>>> this could be an idea but one need the second outlet.
>>> 
>>> ciao
>>> -Marco Matteo Markidis
>> 
>> 
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>> 
>> 
>> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[hans w. koch]

wouldn´t it be more interesting/useful to incorporate a [date] object into 
vanilla pd, from which it would be trivial to generate unique seeds, but which 
also could be used in (many) other contexts?

hans


> Am 31.05.2018 um 19:21 schrieb Dan Wilcox :
> 
> It would relatively easy to add a right outlet to [random]. Another option 
> might be an explicit [seed] object which could give you further control or 
> perhaps some creation flags for [random] as well.
> 
>>> you still have control on the seed... just seed it
>> 
>> no because you need to add an extra outlet to [random] and prints out the
>> seed value.
>> 
>>> or even seed it with the system time on creation?
>> 
>> if one adds now this behaviour one need to put a flag for backward
>> compatibility.
>> 
>>> what if [seed( without argument would take the current system time?
>> 
>> this could be an idea but one need the second outlet.
>> 
>> ciao
>> -Marco Matteo Markidis
> 
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Dan Wilcox]

It would relatively easy to add a right outlet to [random]. Another option 
might be an explicit [seed] object which could give you further control or 
perhaps some creation flags for [random] as well.

>> you still have control on the seed... just seed it
> 
> no because you need to add an extra outlet to [random] and prints out the
> seed value.
> 
>> or even seed it with the system time on creation?
> 
> if one adds now this behaviour one need to put a flag for backward
> compatibility.
> 
>> what if [seed( without argument would take the current system time?
> 
> this could be an idea but one need the second outlet.
> 
> ciao
> -Marco Matteo Markidis


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Marco Matteo Markidis]

>
> you still have control on the seed... just seed it

no because you need to add an extra outlet to [random] and prints out the
seed value.

> or even seed it with the system time on creation?

if one adds now this behaviour one need to put a flag for backward
compatibility.

> what if [seed( without argument would take the current system time?

this could be an idea but one need the second outlet.

ciao
-Marco Matteo Markidis


2018-05-31 17:50 GMT+02:00 Alexandre Torres Porres :

> that's what I was suggesting ;)
>
> 2018-05-31 9:15 GMT-03:00 Christof Ressi :
>
>> just an idea: what if [seed( without argument would take the current
>> system time?
>>
>> or even seed it with the system time on creation?
>>
>> > Gesendet: Donnerstag, 31. Mai 2018 um 13:36 Uhr
>> > Von: "Peter P." 
>> > An: pd-list 
>> > Betreff: Re: [PD] Random
>> >
>> > * Marco Matteo Markidis  [2018-05-30 19:29]:
>> > > usually in random number generators one wants to have control on the
>> seed
>> > > because this allows to have the same numeric streams every time one
>> wants.
>> >
>> > I thought about this and conclude that the help patch should mention the
>> > fact that the sequence is always the same even when the object is not
>> > explicitely seeded with the [seed ...< message.
>> >
>> > ___
>> > Pd-list@lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>> >
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Alexandre Torres Porres]

that's what I was suggesting ;)

2018-05-31 9:15 GMT-03:00 Christof Ressi :

> just an idea: what if [seed( without argument would take the current
> system time?
>
> or even seed it with the system time on creation?
>
> > Gesendet: Donnerstag, 31. Mai 2018 um 13:36 Uhr
> > Von: "Peter P." 
> > An: pd-list 
> > Betreff: Re: [PD] Random
> >
> > * Marco Matteo Markidis  [2018-05-30 19:29]:
> > > usually in random number generators one wants to have control on the
> seed
> > > because this allows to have the same numeric streams every time one
> wants.
> >
> > I thought about this and conclude that the help patch should mention the
> > fact that the sequence is always the same even when the object is not
> > explicitely seeded with the [seed ...< message.
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> >
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Christof Ressi]

just an idea: what if [seed( without argument would take the current system 
time? 

or even seed it with the system time on creation?

> Gesendet: Donnerstag, 31. Mai 2018 um 13:36 Uhr
> Von: "Peter P." 
> An: pd-list 
> Betreff: Re: [PD] Random
>
> * Marco Matteo Markidis  [2018-05-30 19:29]:
> > usually in random number generators one wants to have control on the seed
> > because this allows to have the same numeric streams every time one wants.
> 
> I thought about this and conclude that the help patch should mention the
> fact that the sequence is always the same even when the object is not
> explicitely seeded with the [seed ...< message.
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Chris McCormick]

Hi,

On 31/05/18 04:07, IOhannes m zmölnig wrote:

On 05/30/2018 09:15 PM, Alexandre Torres Porres wrote:

different seed? I can see that with [zexy/time], but not realtime


well [realtime] will give you different results, based on what other
things your CPU is doing. so there *is* a bit of entropy in their.
see roman's patch.


Also this patch which uses network connection, file read, etc. to add 
further entropy:


https://raw.githubusercontent.com/chr15m/SyncJams/master/pure-data/uid.pd
https://raw.githubusercontent.com/chr15m/SyncJams/master/pure-data/uid-help.pd

Chris.

--
http://mccormick.cx/

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Peter P.]

* Marco Matteo Markidis  [2018-05-30 19:29]:
> usually in random number generators one wants to have control on the seed
> because this allows to have the same numeric streams every time one wants.

I thought about this and conclude that the help patch should mention the
fact that the sequence is always the same even when the object is not
explicitely seeded with the [seed ...< message.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[IOhannes m zmölnig]

On 05/30/2018 09:15 PM, Alexandre Torres Porres wrote:
> different seed? I can see that with [zexy/time], but not realtime

well [realtime] will give you different results, based on what other
things your CPU is doing. so there *is* a bit of entropy in their.
see roman's patch.

entropy is probably not very high though, but is probably good enough
for most musical things (we are not talking cryptography here; getting
high entropy is really a hard problem).
and it doesn't depend on any external.

fgamdsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Alexandre Torres Porres]

also use zexy/date then? :)

2018-05-30 14:59 GMT-03:00 Jean-Marie Adrien :

> the text file seems the best since time things might fail cause patch
> opens everyday at the same computer time…
> or maybe take the nanoseconds…which might differ from one occurrence to
> the other ...
>
> > Le 30 mai 2018 à 16:57, Ingo Stock  a écrit :
> >
> > Another way is to generate a random number, save this number and use it
> > as a seed the next time the patch gets opened. This way you will always
> > have a fresh seed.
> >
> > Two examples attached, random.pd saves the seed within the patch,
> > random2.pd saves the seed in a text file. random2.pd throws an error the
> > first time, if the text file is not present.
> >
> > best, ingo
> >
> >
> > On 05/30/2018 04:41 PM, Claude Heiland-Allen wrote:
> >> On 30/05/18 15:17, Jean-Marie Adrien wrote:
> >>> Hi everyone,
> >>> trying to open a patch with a different text on screen each time
> random.
> >>> Used random object as always since 20 years with a loadbang.
> >>> Discovered that this loadbang/random seems to generate always the same
> >>> result on opening
> >>> :)
> >> It's a feature.  But not having non-determinism is a bit awkward
> sometimes.
> >>
> >>> What is the correct way to get a random digit on patch load within say
> >>> 30 choices ?
> >>
> >> You can generate a random number before starting Pd and -send it to your
> >> patch on load.
> >> (requires knowledge of shell/cmd scripting)
> >> (this is the approach I took in my 'dynamo' project:
> >> https://code.mathr.co.uk/dynamo )
> >>
> >> You can try to read raw binary data from /dev/urandom, perhaps with
> >> [soundfiler] or [readsf~]
> >> (requires an OS with this device, and I have not tested it)
> >>
> >> You could try reading from [adc~] or analogue sensor pins
> >> (requires some unpredictable signal input, possibly special hardware)
> >>
> >> You could try [delay] with [realtime]
> >> (you might get one or two bits of randomness each time)
> >>
> >> You could try an external
> >> (maybe some function of calendar time will look random enough? I think
> >> zexy has date support)
> >>
> >>
> >> Claude
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Alexandre Torres Porres]

2018-05-30 14:29 GMT-03:00 Marco Matteo Markidis :

> usually in random number generators one wants to have control on the seed
>

you still have control on the seed... just seed it


> generate a time-valued seed in some way (e.g. [realtime])
>

how would you do something with that, that each time you start pd it has a
different seed? I can see that with [zexy/time], but not realtime
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Jean-Marie Adrien]

the text file seems the best since time things might fail cause patch opens 
everyday at the same computer time…
or maybe take the nanoseconds…which might differ from one occurrence to the 
other ...

> Le 30 mai 2018 à 16:57, Ingo Stock  a écrit :
> 
> Another way is to generate a random number, save this number and use it
> as a seed the next time the patch gets opened. This way you will always
> have a fresh seed.
> 
> Two examples attached, random.pd saves the seed within the patch,
> random2.pd saves the seed in a text file. random2.pd throws an error the
> first time, if the text file is not present.
> 
> best, ingo
> 
> 
> On 05/30/2018 04:41 PM, Claude Heiland-Allen wrote:
>> On 30/05/18 15:17, Jean-Marie Adrien wrote:
>>> Hi everyone,
>>> trying to open a patch with a different text on screen each time random.
>>> Used random object as always since 20 years with a loadbang.
>>> Discovered that this loadbang/random seems to generate always the same
>>> result on opening
>>> :)
>> It's a feature.  But not having non-determinism is a bit awkward sometimes.
>> 
>>> What is the correct way to get a random digit on patch load within say
>>> 30 choices ?
>> 
>> You can generate a random number before starting Pd and -send it to your
>> patch on load.
>> (requires knowledge of shell/cmd scripting)
>> (this is the approach I took in my 'dynamo' project:
>> https://code.mathr.co.uk/dynamo )
>> 
>> You can try to read raw binary data from /dev/urandom, perhaps with
>> [soundfiler] or [readsf~]
>> (requires an OS with this device, and I have not tested it)
>> 
>> You could try reading from [adc~] or analogue sensor pins
>> (requires some unpredictable signal input, possibly special hardware)
>> 
>> You could try [delay] with [realtime]
>> (you might get one or two bits of randomness each time)
>> 
>> You could try an external
>> (maybe some function of calendar time will look random enough? I think
>> zexy has date support)
>> 
>> 
>> Claude
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Marco Matteo Markidis]

usually in random number generators one wants to have control on the seed
because this allows to have the same numeric streams every time one wants.
so, IMHO the best practice is to generate a time-valued seed in some way
(e.g. [realtime]) and use it as argument for |seed< method.

ciao

2018-05-30 19:09 GMT+02:00 Alexandre Torres Porres :

>
>
> 2018-05-30 11:45 GMT-03:00 Martin Peach :
>>
>>
>> This patch uses [time] to seed the random sequence.
>>
>
> I guess this is sort of like how the initial seed is done in Max. Not sure
> exactly, but it uses some time period since the computer started or
> something.
>
> I think it is a good idea to include something like that in [random] so it
> is updated to automatically have a different starting seed every time.
>
> cheers
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Alexandre Torres Porres]

2018-05-30 11:45 GMT-03:00 Martin Peach :
>
>
> This patch uses [time] to seed the random sequence.
>

I guess this is sort of like how the initial seed is done in Max. Not sure
exactly, but it uses some time period since the computer started or
something.

I think it is a good idea to include something like that in [random] so it
is updated to automatically have a different starting seed every time.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Ingo Stock]

Another way is to generate a random number, save this number and use it
as a seed the next time the patch gets opened. This way you will always
have a fresh seed.

Two examples attached, random.pd saves the seed within the patch,
random2.pd saves the seed in a text file. random2.pd throws an error the
first time, if the text file is not present.

best, ingo


On 05/30/2018 04:41 PM, Claude Heiland-Allen wrote:
> On 30/05/18 15:17, Jean-Marie Adrien wrote:
>> Hi everyone,
>> trying to open a patch with a different text on screen each time random.
>> Used random object as always since 20 years with a loadbang.
>> Discovered that this loadbang/random seems to generate always the same
>> result on opening
>> :)
> It's a feature.  But not having non-determinism is a bit awkward sometimes.
> 
>> What is the correct way to get a random digit on patch load within say
>> 30 choices ?
> 
> You can generate a random number before starting Pd and -send it to your
> patch on load.
> (requires knowledge of shell/cmd scripting)
> (this is the approach I took in my 'dynamo' project:
> https://code.mathr.co.uk/dynamo )
> 
> You can try to read raw binary data from /dev/urandom, perhaps with
> [soundfiler] or [readsf~]
> (requires an OS with this device, and I have not tested it)
> 
> You could try reading from [adc~] or analogue sensor pins
> (requires some unpredictable signal input, possibly special hardware)
> 
> You could try [delay] with [realtime]
> (you might get one or two bits of randomness each time)
> 
> You could try an external
> (maybe some function of calendar time will look random enough? I think
> zexy has date support)
> 
> 
> Claude
#N canvas 600 329 313 321 12;
#X obj 40 46 loadbang;
#X msg 152 115 set seed \$1;
#X msg 86 92 seed 168;
#X obj 134 46 namecanvas \$0-this;
#X obj 40 253 print;
#X msg 126 161 menusave;
#X obj 126 184 s \$0-this;
#X obj 40 230 t f f;
#X obj 40 207 random 100;
#X obj 63 115 random 1000;
#X obj 63 138 t f b f;
#X msg 63 161 seed \$1;
#X obj 40 69 t b b b;
#X connect 0 0 12 0;
#X connect 1 0 2 0;
#X connect 2 0 9 0;
#X connect 5 0 6 0;
#X connect 7 0 4 0;
#X connect 8 0 7 0;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 10 1 5 0;
#X connect 10 2 1 0;
#X connect 11 0 8 0;
#X connect 12 0 8 0;
#X connect 12 1 9 0;
#X connect 12 2 2 0;
#N canvas 600 329 313 451 12;
#X obj 47 39 loadbang;
#X obj 139 39 table \$0-seed 1;
#X obj 70 131 tabread \$0-seed;
#X msg 70 108 0;
#X obj 70 200 random 1;
#X msg 102 177 seed \$1;
#X obj 70 154 t b f;
#X obj 116 246 tabwrite \$0-seed;
#X obj 70 223 t f b f;
#X msg 104 85 read seed.txt;
#X obj 104 108 s \$0-seed;
#X obj 93 292 s \$0-seed;
#X msg 93 269 write seed.txt;
#X msg 70 315 seed \$1;
#X obj 47 62 t b b b;
#X obj 47 361 print;
#X obj 47 338 random 100;
#X connect 0 0 14 0;
#X connect 2 0 6 0;
#X connect 3 0 2 0;
#X connect 4 0 8 0;
#X connect 5 0 4 0;
#X connect 6 0 4 0;
#X connect 6 1 5 0;
#X connect 8 0 13 0;
#X connect 8 1 12 0;
#X connect 8 2 7 0;
#X connect 9 0 10 0;
#X connect 12 0 11 0;
#X connect 13 0 16 0;
#X connect 14 0 16 0;
#X connect 14 1 3 0;
#X connect 14 2 9 0;
#X connect 16 0 15 0;


signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Martin Peach]

On Wed, May 30, 2018 at 10:17 AM, Jean-Marie Adrien  wrote:

> Hi everyone,
> trying to open a patch with a different text on screen each time random.
> Used random object as always since 20 years with a loadbang.
> Discovered that this loadbang/random seems to generate always the same
> result on opening
> :)
> What is the correct way to get a random digit on patch load within say 30
> choices ?
>

This patch uses [time] to seed the random sequence.

Martin
#N canvas 681 153 450 443 16;
#X obj 121 96 time;
#X obj 145 133 *;
#X obj 133 169 *;
#X obj 121 207 *;
#X floatatom 121 242 9 0 0 0 - - -;
#X obj 229 81 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 121 275 seed \$1;
#X obj 121 363 print >>>;
#X obj 74 22 loadbang;
#X obj 121 321 random 30;
#X obj 74 59 t b b;
#X connect 0 0 3 0;
#X connect 0 1 2 0;
#X connect 0 2 1 0;
#X connect 0 3 1 1;
#X connect 1 0 2 1;
#X connect 2 0 3 1;
#X connect 3 0 4 0;
#X connect 4 0 6 0;
#X connect 5 0 0 0;
#X connect 6 0 9 0;
#X connect 8 0 10 0;
#X connect 9 0 7 0;
#X connect 10 0 9 0;
#X connect 10 1 0 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Roman Haefeli]

On Wed, 2018-05-30 at 11:30 -0300, José de Abreu wrote:
> if you can use adc~ (assuming that your mic can capture some noise)
> you can sum some snapshots~ with high gain and then voilà, random
> number each time

Attached is a method that doesn't require audio to be on (and thus also
no real adc~). 

Roman#N canvas 9 110 450 300 10;
#X obj 63 206 until;
#X msg 63 229 281.29;
#X obj 63 252 pow 392.1;
#X obj 44 49 t b b b;
#X obj 83 83 realtime;
#X obj 44 21 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 63 183 2;
#X obj 83 106 * 1000;
#X obj 83 129 int;
#X floatatom 83 152 10 0 0 0 - - -, f 10;
#X text 150 152 seed;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 3 0 4 1;
#X connect 3 1 6 0;
#X connect 3 2 4 0;
#X connect 4 0 7 0;
#X connect 5 0 3 0;
#X connect 6 0 0 0;
#X connect 7 0 8 0;
#X connect 8 0 9 0;


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Claude Heiland-Allen]

On 30/05/18 15:17, Jean-Marie Adrien wrote:

Hi everyone,
trying to open a patch with a different text on screen each time random.
Used random object as always since 20 years with a loadbang.
Discovered that this loadbang/random seems to generate always the same result 
on opening
:)

It's a feature.  But not having non-determinism is a bit awkward sometimes.


What is the correct way to get a random digit on patch load within say 30 
choices ?


You can generate a random number before starting Pd and -send it to your 
patch on load.

(requires knowledge of shell/cmd scripting)
(this is the approach I took in my 'dynamo' project: 
https://code.mathr.co.uk/dynamo )


You can try to read raw binary data from /dev/urandom, perhaps with 
[soundfiler] or [readsf~]

(requires an OS with this device, and I have not tested it)

You could try reading from [adc~] or analogue sensor pins
(requires some unpredictable signal input, possibly special hardware)

You could try [delay] with [realtime]
(you might get one or two bits of randomness each time)

You could try an external
(maybe some function of calendar time will look random enough? I think 
zexy has date support)



Claude
--
https://mathr.co.uk


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[José de Abreu]

if you can use adc~ (assuming that your mic can capture some noise) you can
sum some snapshots~ with high gain and then voilà, random number each time

Em Qua, 30 de mai de 2018 11:18, Jean-Marie Adrien 
escreveu:

> Hi everyone,
> trying to open a patch with a different text on screen each time random.
> Used random object as always since 20 years with a loadbang.
> Discovered that this loadbang/random seems to generate always the same
> result on opening
> :)
> What is the correct way to get a random digit on patch load within say 30
> choices ?
> Tks
> JM
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Random thoughts after 1 year with PD

[William Huston]

This is coming up on my first year
as a PD hacker.

Having so much fun.
I think I'm obsessed.

One thing I am really digging about PD is that after 1 year,
I feel I have a basic grasp of about 20% of the PD objects
(i think I am including extended here)
and maybe 60% of the paradigm.



* Even with this limited subset, I can build pretty much anything I want! *
I have a collection of abstractions for LFOs, Multi-waveform oscillators,
sample-loopers, basic effects, reverb and delay, sequencers, ADSR,
basic LP, BP, and HP filters, etc. Ring Modulation, I have little modules
that deal MIDI, etc.


*Here's my observation*
*which I wanted to share:*


*Each time when I want to make music, I find myself building a custom
instrument.*

So the music I make with it seems fresh and different each time.
I make music that surprises me!

Because--
I am not sitting down with any per-conceived ideas
of how to interact with the instrument.
...because it's something brand new every time!
I don't know what it does exactly,

So every session with it becomes an exploration
of the instrument, and an exploration with sounds.

Sometimes something which initially seems
like a bug with the interface,
turns out to be a creative opportunity.

(like the way a slider with a very large range
will jump around to certain discrete points.)

And you think I wish that would move more fluidly.
I wish this controller had more resolution (etc).

But because of this bug,
I've discovered micro-tonal scales.

I first noticed this with Martin Neimoller's Chaos Monster,
these strange but wonderful microtonal scales.

It's really the secret to recreating the music of
India, Iran, the middle east, and also far east.

So anyway, thanks Miller
for this incredible thing.

I really think PD is the *Perfect Instrument*
from *Orson Scott Card's *short story
*Unaccompanied Sonata*.

I have dreamed about having this capability
to mangle sound like this,
for many years, since I was a young boy,

I never thought I would see anything
like this in my lifetime.

I think Pure Data has, in a way,
set my soul free...

And also thanks
to this amazingly supportive community!

Good on ye!
BH



-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list