25 Jan
2010
25 Jan
'10
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.