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
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
"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
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
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
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
> 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
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 us
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
siduum.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/pl
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
(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
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 automatica
* 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.
* 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.
>
> 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.
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
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
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
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,
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
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
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
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
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
>
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
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
t;
>> 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:
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
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
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
* 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
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
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-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
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,
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 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
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
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
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
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
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
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
44 matches
Mail list logo
