24 Jan
2010
24 Jan
'10
6:45 a.m.
In considering a rand() -> random() -> random_r() transition, is the random_r()
family considered "cool for school"? Or are they simply not worth the bother
given the srandom_r() segfault (easily resolved) and a "non-standard glibc
extensions" tag.
cheers, Cal
25 Jan
25 Jan
2:10 p.m.
cal wrote:
In considering a rand() -> random() ->
random_r() transition, is the random_r()
family considered "cool for school"? Or are they simply not worth the bother
given the srandom_r() segfault (easily resolved) and a "non-standard glibc
extensions" tag.
You didn't say what you're using the random numbers for. Even crappy old rand()
would possibly be ok for some applications and completely useless for others.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
5:26 p.m.
Erik de Castro Lopo wrote:
cal wrote:
A little too embarrassed to admit what I was really up to - I'm just exploring a
little side track of interest with Yoshimi (ZynAddSubFX derivative). One of the
motivating factors was Zyn attempting to use a different seed (and sequence?) in
association with each note's elaboration, then reseed->resume the general purpose
randoms. I don't question the original authors intention there, and I'm
admittedly
fuzzy on just what he's doing. I got to wondering if random_r might enable two
independent seed/sequences, eliminating the hold->re-seed->use new
sequence->restore
old seed/sequence on every note. I've now got random_r in there and I'm
comfortable
with it, but at this stage I've no clear indication I've achieved anything
valuable
or even better :-).
cheers, Cal
In considering a rand() -> random() ->
random_r() transition, is the random_r()
family considered "cool for school"? Or are they simply not worth the bother
given the srandom_r() segfault (easily resolved) and a "non-standard glibc
extensions" tag.
You didn't say what you're using the random numbers for. Even crappy old rand()
would possibly be ok for some applications and completely useless for others. 
6:06 p.m.
On Tue, 26 Jan 2010, cal wrote:
old seed/sequence on every note. I've now got
random_r in
there and I'm comfortable with it, but at this stage I've
no clear indication I've achieved anything valuable or
even better :-).
From 'man 3 random_r':
These functions are the reentrant equivalents of the
functions described in random(3). They are suitable for
use in multithreaded programs where each thread needs to
obtain an independent, reproducible sequence of random
numbers.
That is to say, if you need a reproduceable string of
"random" numbers on each thread (e.g. for unit testing),
then random_r() is your man. Otherwise, it sounds like more
trouble than it's worth.
I.e. if every thread is just doing srandom_r(time(),buf),
it's probably not worth it.
If random() is implemented without memory guards (atomic
ops) on the global variable... then it's possible that
calling random() from two different threads at the same time
could give the same answer -- but so what?
-gabriel
6:44 p.m.
Gabriel M. Beddingfield wrote:
On Tue, 26 Jan 2010, cal wrote:
As I understand it, zyn
wants a reproducible sequence for mainstream,
plus a reproducible per note sequence seeded according to the current
point in the mainstream sequence. Interrupting and resuming the
mainstream sequence was the issue I was looking to simplify. If you step
over srandom_r(), it's really not any great trouble.
.
old seed/sequence on every note. I've now got
random_r in there and
I'm comfortable with it, but at this stage I've no clear indication
I've achieved anything valuable or even better :-).
From 'man 3 random_r':
These functions are the reentrant equivalents of the
functions described in random(3). They are suitable for
use in multithreaded programs where each thread needs to
obtain an independent, reproducible sequence of random
numbers.
That is to say, if you need a reproduceable string of "random" numbers
on each thread (e.g. for unit testing), then random_r() is your man.
Otherwise, it sounds like more trouble than it's worth. I.e. if every thread is just doing
srandom_r(time(),buf), it's probably
not worth it.
Probably true, but that's not quite the scenario being addressed.
I saw
potential value in reducing the per note ops going on.
If random() is implemented without memory guards
(atomic ops) on the
global variable... then it's possible that calling random() from two
different threads at the same time could give the same answer -- but so
what?
Good question! Some times you simply have to have that little bit of extra
quality of randomness in your life, even if it's just to make you imagine
you feel better.
cheers.
6:51 p.m.
Gabriel M. Beddingfield wrote:
The placebo randomness affect...
Patrick Shirkey
Boost Hardware Ltd
On Tue, 26 Jan 2010, cal wrote:
As I understand it, zyn wants a reproducible sequence for mainstream,
plus a reproducible per note sequence seeded according to the current
point in the mainstream sequence. Interrupting and resuming the
mainstream sequence was the issue I was looking to simplify. If you step
over srandom_r(), it's really not any great trouble.
.
old seed/sequence on every note. I've now got
random_r in there and
I'm comfortable with it, but at this stage I've no clear indication
I've achieved anything valuable or even better :-).
From 'man 3 random_r':
These functions are the reentrant equivalents of the
functions described in random(3). They are suitable for
use in multithreaded programs where each thread needs to
obtain an independent, reproducible sequence of random
numbers.
That is to say, if you need a reproduceable string of "random" numbers
on each thread (e.g. for unit testing), then random_r() is your man.
Otherwise, it sounds like more trouble than it's worth.
I.e. if every thread is just doing
srandom_r(time(),buf), it's probably
not worth it.
Probably true, but that's not quite the scenario being addressed. I saw
potential value in reducing the per note ops going on.
If random() is implemented without memory guards
(atomic ops) on the
global variable... then it's possible that calling random() from two
different threads at the same time could give the same answer -- but so
what?
Good question! Some times you simply have to have that little bit of extra
quality of randomness in your life, even if it's just to make you imagine
you feel better.
6:59 p.m.
On Tue, 26 Jan 2010, Patrick Shirkey wrote:
Good question!
Some times you simply have to have that little bit of extra
quality of randomness in your life, even if it's just to make you imagine
you feel better.
The placebo randomness affect... From 'man 3 random_placebo':
If rand(), random(), and random_r() aren't random
enough for you, random_placebo() is generates
more randomer numbers by algorthmically generating
more entropies on your system. The return is
guaranteed be the most random number you could
imagine.
:-)
-gabriel
26 Jan
26 Jan
4:08 a.m.
On Tuesday 26 January 2010 01:57:05 drew Roberts wrote:
On Monday 25 January 2010 17:59:36 Gabriel M.
Beddingfield wrote:
I tell you guys, 21 is only half the answer...
he return is
guaranteed be the most random number you could
imagine.
I think you can get this by a simple call to rnd.i()
Now, if you want to make your randomness complex rather than imaginary... 
8:40 a.m.
On Tuesday 26 January 2010 03:08:14 Arnold Krille wrote:
On Tuesday 26 January 2010 01:57:05 drew Roberts
wrote:
Wait! What was the question again?
On Monday 25 January 2010 17:59:36 Gabriel M.
Beddingfield wrote:
I tell you guys, 21 is only half the answer... he return is
guaranteed be the most random number you could
imagine.
I think you can get this by a simple call to rnd.i()
Now, if you want to make your randomness complex rather than imaginary... 
27 Jan
27 Jan
6:49 a.m.
On 01/25/2010 11:59 PM, Gabriel M. Beddingfield wrote:
From 'man 3 random_placebo':
If rand(), random(), and random_r() aren't random
enough for you, random_placebo() is generates
more randomer numbers by algorthmically generating
more entropies on your system. The return is
guaranteed be the most random number you could
imagine.
42?
25 Jan
25 Jan
7:01 p.m.
On Tue, 26 Jan 2010, cal wrote:
Kind of like where the random number generator is part of
the envelope, huh? That makes sense... in which case
random_r() would be a good use for that.
-gabriel
That is to
say, if you need a reproduceable string of "random" numbers
on each thread (e.g. for unit testing), then random_r() is your man.
Otherwise, it sounds like more trouble than it's worth.
As I understand it,
zyn wants a reproducible sequence for mainstream,
plus a reproducible per note sequence seeded according to the current
point in the mainstream sequence. Interrupting and resuming the
mainstream sequence was the issue I was looking to simplify. If you step
over srandom_r(), it's really not any great trouble.
26 Jan
26 Jan
4:12 a.m.
On Tuesday 26 January 2010 00:01:50 Gabriel M. Beddingfield wrote:
On Tue, 26 Jan 2010, cal wrote:
Kind of like where the random number generator is part of
the envelope, huh? That makes sense... in which case
random_r() would be a good use for that.
I don't (yet) get the reason for doing this. If the global seed is initiated
with time() it is the same as if each notes seed is initiated with time(), the
numbers are still random beginning from that seed. The only problems I can see
is when the random numbers are correlated resulting with per-note correlation
of for example always the a of the adsr being to short. A problem that is
easily solved when multiple notes get their numbers from the same seed
effectively randomizing the access to that seed and thus overcoming the
correlation...
Arnold
That is
to say, if you need a reproduceable string of "random" numbers
on each thread (e.g. for unit testing), then random_r() is your man.
Otherwise, it sounds like more trouble than it's worth.
As I understand it, zyn wants a reproducible sequence for mainstream,
plus a reproducible per note sequence seeded according to the current
point in the mainstream sequence. Interrupting and resuming the
mainstream sequence was the issue I was looking to simplify. If you step
over srandom_r(), it's really not any great trouble.
5:03 a.m.
Arnold Krille wrote:
[ ... ]
I don't (yet) get the reason for doing this. If the global seed is initiated
with time() it is the same as if each notes seed is initiated with time(), the
numbers are still random beginning from that seed. The only problems I can see
is when the random numbers are correlated resulting with per-note correlation
of for example always the a of the adsr being to short. A problem that is
easily solved when multiple notes get their numbers from the same seed
effectively randomizing the access to that seed and thus overcoming the
correlation...
I can't come up with any better response than ... sounds feasible.
8:34 a.m.
On Tue, 26 Jan 2010, Arnold Krille wrote:
I don't (yet) get the reason for doing this. If
the global seed is initiated
with time() it is the same as if each notes seed is initiated with time(), the
*Is* each note being seeded with time()??
I got the impression that the seeds were being saved and
repeated. The reason why /that/ might make sense is if the
PRNG is being used for some kind of modulation effect -- and
then all the notes would have an identical "sound."
-gabriel
9:23 a.m.
Hi,
On Tuesday 26 January 2010 13:33:52 Gabriel M. Beddingfield wrote:
On Tue, 26 Jan 2010, Arnold Krille wrote:
I don't know but this sounds a bit stupid to me. You want the random numbers
to have differences. Playing the same note again on a real piano or violin
still produces different sounds each time. So I would expect a synth using
random numbers for variety to behave the same and not give me exactly the same
each time I hit that note.
But regardless at how the seeds are initialized, when you use a special seed
for each note, you are very much effected by correlation of the random numbers.
When using the same seed for all notes, the access to the seed gets randomized
as soon as you hit two notes together. Which reduces the effect of bad random
numbers.
And you can't really use scientific random number generators because you want
to be fast and have realtime with the synth, so you are bound to have some
strange effects from the random numbers.
Arnold
I don't (yet) get the reason for doing this.
If the global seed is
initiated with time() it is the same as if each notes seed is initiated
with time(), the
*Is* each note being seeded with time()??
I got the impression that the seeds were being saved and
repeated. The reason why /that/ might make sense is if the
PRNG is being used for some kind of modulation effect -- and
then all the notes would have an identical "sound." 
9:30 a.m.
On Tue, 2010-01-26 at 14:23 +0100, Arnold Krille wrote:
I don't know but this sounds a bit stupid to me.
You want the random numbers
to have differences. ...
And you can't really use scientific random number
generators because you want
to be fast and have realtime with the synth ...
I am surprised that nobody so far has suggested using the key and
velocity as a "salt" to differentiate a single stream of randomness?
8:27 a.m.
On 01/27/2010 12:31 PM, cal wrote:
Jens M Andreasen wrote:
http://en.wikipedia.org/wiki/Salting_%28cryptography%29
[ ... ]
I am surprised that nobody so far has suggested using the key and
velocity as a "salt" to differentiate a single stream of randomness?
If you don't mind, how would one go about "salting" it?
9:10 a.m.
Jörn Nettingsmeier wrote:
On 01/27/2010 12:31 PM, cal wrote:
Cool, thanks!
Jens M Andreasen wrote:
http://en.wikipedia.org/wiki/Salting_%28cryptography%29 [ ... ]
I am surprised that nobody so far has suggested using the key and
velocity as a "salt" to differentiate a single stream of randomness?
If
you don't mind, how would one go about "salting" it?
8:54 a.m.
On Wed, 27 Jan 2010, cal wrote:
Jens M Andreasen wrote:
One way that comes to mind:
unsigned short int note, velocity;
// ...
unsigned int salt = ((velocity & 0x7F)<<7) | (note & 0x7F);
struct random_data seed;
srandom_r(salt, &seed);
Thus, if you repeat the note with identical velocity...
you'll always get the same random-number sequence.
-gabriel
[ ... ]
I am surprised that nobody so far has suggested using the key and
velocity as a "salt" to differentiate a single stream of randomness?
If you don't mind, how would one go about "salting" it?
9:48 a.m.
On Thu, 28 Jan 2010, cal wrote:
Gabriel M. Beddingfield wrote:
Wow. random_r() is /really/ poorly documented.
Non-segfaulting example attached.
-gabriel
[ ... ]
srandom_r(salt, &seed);
Thus, if you repeat the note with identical velocity... you'll always
get the same random-number sequence.
or do you just get a segfault :-) ?
11:28 a.m.
Gabriel M. Beddingfield wrote:
On Thu, 28 Jan 2010, cal wrote:
Yeah, I too wandered innocently into the parallel universe alluded to here
(and no doubt elsewhere) <http://sourceware.org/bugzilla/show_bug.cgi?id=3662>.
I thought wow, that was 2006! Surely it's been sorted by now. Apparently not.
Cheers.
Gabriel M. Beddingfield wrote:
Wow. random_r() is /really/ poorly documented. Non-segfaulting example
attached. [ ... ]
srandom_r(salt, &seed);
Thus, if you repeat the note with identical velocity... you'll always
get the same random-number sequence.
or do you just get a segfault :-) ? 
10:37 a.m.
On Wed, 27 Jan 2010 06:54:00 -0600 (CST)
"Gabriel M. Beddingfield" <gabrbedd(a)gmail.com> wrote:
On Wed, 27 Jan 2010, cal wrote:
Hmmm,
Getting identical note and velocity is going to be quite common on
sequencer generated stuff, so I would have thought this was rather
undesirable. While there have been odd occasions when I've wished I
could reliably re-create a pseudo random sequence, in general I would
not want repeated identically created notes to sound exactly the same.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Jens M Andreasen wrote:
One way that comes to mind:
unsigned short int note, velocity;
// ...
unsigned int salt = ((velocity & 0x7F)<<7) | (note & 0x7F);
struct random_data seed;
srandom_r(salt, &seed);
Thus, if you repeat the note with identical velocity...
you'll always get the same random-number sequence.
-gabriel [ ... ]
I am surprised that nobody so far has suggested using the key and
velocity as a "salt" to differentiate a single stream of randomness?
If you don't mind, how would one go about "salting" it?
10:50 a.m.
On Wed, 27 Jan 2010, Folderol wrote:
Hmmm,
Getting identical note and velocity is going to be quite common on
sequencer generated stuff, so I would have thought this was rather
undesirable. While there have been odd occasions when I've wished I
could reliably re-create a pseudo random sequence, in general I would
not want repeated identically created notes to sound exactly the same.
Agreed... but apparently cal /does/ want that. :-)
Related example: THX's "Deep Note" was composed using a
PRNG. Every performance was different. The "favorite"
performance is the one you hear in theaters (with the
descending overtones at the end). At one point, the
recording was lost -- and there was no way to recreate
it.[1] If they had saved the seeds to the PRNG's, they could
have recreated the performance (even with rand()).
-gabriel
[1] http://en.wikipedia.org/wiki/Deep_Note
Sorry, can't find a reference ATM for the story about
losing the master recording.
11:35 a.m.
Gabriel M. Beddingfield wrote:
On Wed, 27 Jan 2010, Folderol wrote:
Not quite. Over the last 12 months I've learned that I don't know enough
about how zyn does its maths magic to try to change how it does it too
radically. All I wanted was the same behavior as original zyn, but
simpler code. One day I might get more adventurous, but I'm not there yet.
Cheers.
Hmmm,
Getting identical note and velocity is going to be quite common on
sequencer generated stuff, so I would have thought this was rather
undesirable. While there have been odd occasions when I've wished I
could reliably re-create a pseudo random sequence, in general I would
not want repeated identically created notes to sound exactly the same.
Agreed... but apparently cal /does/ want that. :-)
5364
days inactive
5367
days old
linux-audio-dev@lists.linuxaudio.org
26 comments
9 participants
participants (9)
-
Arnold Krille -
cal -
drew Roberts -
Erik de Castro Lopo -
Folderol -
Gabriel M. Beddingfield -
Jens M Andreasen -
Jörn Nettingsmeier -
Patrick Shirkey