[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] phasor calcfunc


On 23 Dec 2009, at 15:22, James Harkins wrote:

if (unit->mCalcRate == calc_FullRate) {
if (INRATE(0) == calc_FullRate) {
if (INRATE(1) == calc_FullRate) {
SETCALC(Phasor_next_aa);
} else {
SETCALC(Phasor_next_ak);
}
} else {
SETCALC(Phasor_next_kk);
}
} else {
SETCALC(Phasor_next_ak);
}

This seems odd to me, but maybe I misunderstand.

If the unit is audio rate and its first two inputs are audio rate, use _aa (makes sense).
If the unit is audio rate and its trigger is audio rate but rate is control, use _ak.
If it's audio rate and its first two inputs are control, use _kk (huh wtf?).

That's right. It will still calculate at audio rate, but it only needs to read the two inputs at kr. Remember the names are only to do with the inputs. ar vs kr is determined effectively by inNumSamples.


if its control rate, use _ak (again, huh?).

Won't do anything dodgy as inNumSamples is 1. 

S.



Shouldn't the last two be flipped so it looks like this?

if (unit->mCalcRate == calc_FullRate) {
if (INRATE(0) == calc_FullRate) {
if (INRATE(1) == calc_FullRate) {
SETCALC(Phasor_next_aa);
} else {
SETCALC(Phasor_next_ak);
}
} else {
SETCALC(Phasor_next_ak);
}
} else {
SETCALC(Phasor_next_kk);
}

(I was surprised to see that my example was using next_ak when the unit is control rate and all its inputs are either control or scalar.)

hjh



: H. James Harkins
.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman