[chuck-users] UGen v.s. code in timing; very tricky
signal.automatique at gmail.com
Thu Sep 18 12:07:32 EDT 2008
> I would actually think it might truncate either up or down depending on the
> extra place value (but I don't know enough about how floating point
> truncation works to tell you). Does this behavior change from language to
> language - or architecture to architecture?
I'd imagine that it does. In audio, BTW, if we're going to be rounding (and
we are) I could imagine that rounding towards 0 could avoid exploding
feedback loops. Rounding means noise and we wouldn't want noise to build up.
I'm really just speculating here but it sounds like a nice idea to me right
Another thing is that I'm not sure at what point the .phase() is actually
>> calculated. When you call to .last() you get the sample at the last UGen
>> tick so that value is at that point on average .5::samp out of date. I'm not
>> sure whether .phase() is also calculated at that moment or whether it can be
>> calculated in between ticks. This could be another factor.
> well this one is easy to figure out:
Ok... so that would mean this factor would make the zero crossing appear
sooner then we'd expect it as we're calculating it based on "out of date"
data. This is looking more and more tricky with various factors pulling the
outcome in both directions, apparently.
I'm tempted to guess that it's not possible unless we could calculate an
> audio sample before it is reached i.e. s.next() but I don't think Chuck
> has that capability (yet). But please prove me wrong!
I'm going to look into this (I do think it should be possible, that next
sample is based on factors we can know) but I also have a sound-design gig
that requires quite a bit of material and that needs to be done by Monday...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users