[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