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.

Well, now, "lousy chucker" is really quite exaggerated. Calculation order and so on is really a quite advanced subject that nobody notices until it mysterious mucks everything up. At least it's predictable in most practical ChucK situations which can save a lot of noise compared to some other systems.

I'd say you are a good listener instead, I might've missed why things were out of tune myself. :¬)

...in fact, now that I think of it, I might've missed this in some of my own code, I could probably tighten up a rhythmical delay I use.

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.

So, if I get this right, you made sure the delay now works at it's set length for both feedback and straight output?

That would be quite a valuable addition if you'd submit it (not sure if there's a official process for this). At any rate this phenomenon could stand some attention in the manual because any system using feedback will run into this. Often the Z-1 function inherent in the feedback is actually beneficial and useful but we should probably document that it's there, where it is exactly and how it will affect things.

Glad to have been of help. I hope you'll share your fix, sounds like a solution that would be good for everyone.

Yours,
Kas.