[chuck-users] Tracking down clicks and pops..

[Kassen]

>
>
> Questions: How does chuck handle concurrancy with time and threads? If any
> one thread advances time, it advances time for the whole VM right? My loop
> for the modulators advances time by 1::ms or else the program just spins
> forever - the rest of the program isn't ever reached. Is there a better way
> to do this? The loop is just a while(true) loop with a 1::ms => now at the
> end (after setting the parameters) ... but this thread doesn't actually own
> the osc's, it's a child of that thread. Maybe I'm getting into a bugger
> here?
>
>
Essentially "second => now;" can be translated as "I (as a shred) am done
using the cpu for now and want it back in a second", handing on the service
of the cpu to other processes that might need it. When no shred uses the cpu
right "now" the cpu can be busy calculating UGens, if that too is done then
the cpu can take a rest or tend to stuff like your incoming mail.

If you'd like to know more about the why and how of it all then I recommend
you look at Ge's thesis; https://ccrma.stanford.edu/~ge/thesis.html That's
probably the best source of info on the reasoning behind it all (really,
there is some! :-p ). I recommend that one to anyone looking to understand
more about ChucK's internal workings.

Shreds, BTW, don't "own" UGens. They may be in the same name-space though,
so a shred can address a UGen. A UGen may *only* be addressable by a given
shred (due to being defined in it) in which case the death of the shred will
mean the end of the UGen's life too (as the UGen will lack references). As
long as they are in the same name-space the UGen will be addressable and
beyond that it shouldn't make a difference.

I hope that clarifies,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20110612/5f596d14/attachment.htm>