Eric Hedekar

Ah, the digital world - never enough bits! My first reaction was to think that this extra sample was a floating point truncation error in the s.phase() and s.period() math, but then I came to think hmm... would those minuscule fractions of samples make any difference to a zero crossing timing?

Yes, those are good questions. Of course a samp is a very short period but thanks to double floats we have a almost obscene amount of resolution at that scale. I also think that floating point errors only become significant when multiplying very large numbers with very small ones, which I don't think is the case here (but I'm not sure).

Furthermore, why would a truncation error be weighted?

That bit may not be very hard; it may well be the case that if the floats when truncated are truncated towards zero. As we are always dealing with positive numbers that could explain something?

Your declaration that "the value is on -average- lower in magnitude" started me thinking 'okay, how average?' So I wrote up a little script:

Ah-Ha! A scientific approach to investigating a unknown phenomena. :¬) I'll admit, at first I didn't have the zero crossing checks in, so I was

understanding very little, but once I realized that the zero crossings were equally distributed between the two possible locations, things clicked. Obviously the extra sample would "on average" (about 75% of the time) result in a lower s.last() value, because it's the sample around which the zero crossing would pivot. If the zero crossing didn't pivot, then you'd see an even distribution of probability for the lowest value.

I think you are right.

Your initial calculation is advancing time to the end of the period (or so it tries). I think there is a truncation error that is hidden in the math (that would explain why the zero crossing is jumping back and forth between the two locations, with an even distribution), and therefore only half the time you've advanced fully to the end of the period (the other half of the time you're off by one sample).

Hmmmm, I really would expect it to truncate towards zero. 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.

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'd unchuck items with the inclusion of a while loop: while (s.gain()>0.000000001) { s.gain()/1.005 => s.gain(); samp=>now; } s =< dac;

Though who knows how long that can take.

That will indeed work but that's far from cheap. For audio range signals this should finish sooner (nearly always) while (Std.fabs(s.last()) >0.000000001) { s.gain()/1.005 => s.gain(); samp=>now; } s =< dac; ...but to be honest what I did was simply bring in a Envelope and ramp down over 50::ms which is always click-free though it could have a spectral effect when the context is some granular technique. Very interesting matter, thanks a lot for your help! Yours, Kas.

Eric Hedekar;

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 now.... 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... Yours, Kas.

2008/9/19 Paul Reiners

What is the maximum value of an int in ChucK? Is there a symbolic constant for it?

New in the latest version! <<>>; Yours, Kas.