<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Sep 18, 2008 at 7:23 AM, Kassen <span dir="ltr"><<a href="mailto:signal.automatique@gmail.com">signal.automatique@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div class="gmail_quote"><div><br>Hmmmm, I really would expect it to truncate towards zero.</div></div></div></blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div> 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.<br>
</div></div></div></blockquote><div><br>well this one is easy to figure out:<br><br> SinOsc s => dac;<br>30::ms=>now;<br><<<s.phase()>>>;<br>0.5::samp=>now;<br><<<s.phase()>>>;<br>
0.5::samp=>now;<br><<<s.phase()>>>;<br><br>returns:<br>0.600000 :(float)<br>0.600000 :(float)<br>0.604583 :(float)<br><br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div class="gmail_quote"><div><br> </div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">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.</div>
</blockquote></div><div><br>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.<br>
</div></div></div></blockquote><div> </div></div>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!<br>
<br>-Eric Hedekar<br clear="all"><br>-- <br>_______________________________________<br> <a href="http://greyrockstudio.blogspot.com">http://greyrockstudio.blogspot.com</a><br>
</div>