On Wed, Dec 23, 2009 at 11:47 AM, Scott Wilson
<s.d.wilson.1@xxxxxxxxxx> wrote:
On 23 Dec 2009, at 17:18, James Harkins wrote:
if its control rate, use _ak (again, huh?).
Won't do anything dodgy as inNumSamples is 1.
I understand, though it does mean Phasor.kr uses more complex, less-optimized code than Phasor.ar with control rate inputs! That could be safely changed I think.
Just observing that next_ak has this (to handle triggers mid-control-block) that is irrelevant for a kr ugen. So, why invoke it when it's meaningless at control rate?
float curin = ZXP(in);
if (previn <= 0.f && curin > 0.f) {
float frac = 1.f - previn/(curin-previn);
level = resetPos + frac * rate;
}
vs. trigger handling in next_kk:
if (previn <= 0.f && in > 0.f) {
level = resetPos;
}
... which is outside the LOOP(inNumSamples).
hjh