[chuck-users] UGen v.s. code in timing; very tricky

Eric Hedekar 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;
30::ms=>now;
<<<s.phase()>>>;
0.5::samp=>now;
<<<s.phase()>>>;
0.5::samp=>now;
<<<s.phase()>>>;

returns:
0.600000 :(float)
0.600000 :(float)
0.604583 :(float)




>
>
>> 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!

-Eric Hedekar

-- 
_______________________________________
    http://greyrockstudio.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080918/7c0ee4eb/attachment.html>


More information about the chuck-users mailing list