[chuck-users] UGen v.s. code in timing; very tricky
afterthebeep at gmail.com
Thu Sep 18 11:34:39 EDT 2008
On Thu, Sep 18, 2008 at 7:23 AM, Kassen <signal.automatique at gmail.com>wrote:
> Hmmmm, I really would expect it to truncate towards zero.
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?
> 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:
SinOsc s => dac;
>> The calculation is not finding the sample closest to the zero crossing -
>> which might be a more precise, yet more laborious approach with little real
>> world improvement.
> I think it could be done by dividing the " (1-s.phase())::s.period()" by a
> samp, then rounding to the nearest integer and advancing time by that many
> samples, however that's assuming "(1-s.phase())::s.period()" doesn't cause
> rounding errors itself, a asumption that now seems far from safe. Also; this
> would demand that we know how the shred's timing and the UGen ticks line up
> as we want to disconnect right after the lowest sample and not right before.
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users