Erik de Castro Lopo wrote:
> 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.

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
 
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Reply via email to