[chuck-users] delay times of STK delays seem to be 1 sample off?
volker böhm
vboehm at gmx.ch
Sat Mar 1 11:20:12 EST 2008
On 29 Feb 2008, at 21:10, Kassen wrote:
>
> ChucK uses a "pull through" model to calculate samples. So; every
> time the DAC wants to output a sample the DAC asks (pulls) all
> Ugens connected to it to report a value and those in turn ask all
> their inputs for one before returning it (recursively). This works
> very well and guarantees a proper calculation order of samples
> (compare that to MAX which uses a left to right evaluation and PD
> which calculates modules in the order they are placed, I think).
>
> All is well until we use feedback. If the DAC depends on a delay
> and that delay in turn depends on itself we would get stuck so
> there we stop and the sample used there is actually the *last*
> sample the delay calculated. This last sample is called the
> "Z-1" (two samples ago would be "Z-2", etc).
thanks for your answer, kassen.
you have a good point here. i'm a lousy chucker and simply needed
some feedback with the delay ugens.
but yes, it can't work like this - at least not correctly.
but what did confuse me in the first place was that i had already
tried to add a feedback path in the ugen source, only to find, that
the timing still wasn't right. that led me to the conclusion that
there must be something wrong with the way the delay time is
calculated - sorry that was a little fast. i did some further tests
and delay times are indeed set correctly.
the problem i ran into, is related to the "Writing before reading
allows delays from 0 to length-1" - approach, which is stated in the
source.
i changed the order of write and read, added a feedback parameter and
everything is fine.
thanks,
volker.
More information about the chuck-users
mailing list