Juan Gil

For those who have studied Eric Lyon's book, or for those who can understand audio programming better than me, I have a question regarding the algorithm to make a variable delay object in Chapter 4, vdelay~:

In the perform routine, the core of the algorithm to store the input sample in the delay line and then read an output sample from it, is shown as:

2 delay_line[write_idx++] = *input++ + (out_sample * feedback);

In case that the delay is set to zero, I would expect the input sample to go through the object with no delay at all. However, when I analysed the simplified code above, I see that the 

 sample until one cycle through the delay line, and that is because 

 was read from the delay line before storing the input in the delay line in the same address.

Is the next a correct way of ensuring that when the delay is zero, the input goes through the object? That means that when interpolation is added to the algorithm, the calculation of the 

 is done twice, before and after storing the 

 sample in the delay line (line number 2):

3 *output++ = delay_line[read_idx]; //to ensure that the input sample goes out when read_idx = write_idx!

In the perform routine,  the core of the algorithm to store the input sample in the delay line and then read an output sample from it, is shown as:
0    read_idx = write_idx - delay;
1    out_sample =  delay_line[read_idx];
2    delay_line[write_idx++] = *input++ + (out_sample * feedback);
3    *output++ = out_sample;

Assuming that feedback=0, and that delay=0, this code would simplify to:
0    read_idx = write_idx;
1    out_sample =  delay_line[read_idx];
2    delay_line[write_idx++] = *input++;
3    *output++ = out_sample;

In case that the delay is set to zero, I would expect the input sample to go through the object with no delay at all. However, when I analysed the simplified code above, I see that the *input++ sample is not written to the *output++ sample until one cycle through the delay line, and that is because out_sample was read from the delay line before storing the input in the delay line in the same address.

Is the next a correct way of ensuring that when the delay is zero, the input goes through the object? That means that when interpolation is added to the algorithm, the calculation of the interp_sample  is done twice, before and after storing the *input++ sample in the delay line (line number 2):
0    read_idx = write_idx;
1    out_sample =  delay_line[read_idx];
2    delay_line[write_idx++] = *input++;
3    *output++ = delay_line[read_idx]; //to ensure that the input sample goes out when read_idx = write_idx!


about-vdelay-from-designing-audio-objects-for-maxmsp-and-pd

i didn't read Eric Lyon's book, but in any feedback-delay algorithm in the numeric world ; needn't the delay variable be a minimum of 1 ? so as to actually allow feedback ; if you don't it's an infinite loop larsen... Sure enough if feedback ==0 then that causes no trouble, but then you must probably make of this a special case, where delay ==0 and feedback == 0 ; and execute the direct output case only when each of those conditions have been matched

but my understanding of your code is limited... sorry if i'm saying useless stuff

i didn't read Eric Lyon's book, but in any feedback-delay algorithm in the numeric world ; needn't the delay variable be a minimum of 1 ? so as to actually allow feedback ; if you don't it's an infinite loop larsen... Sure enough if feedback ==0 then that causes no trouble, but then you must probably make of this a special case, where delay ==0  and feedback == 0 ; and execute the direct output case only when each of those conditions have been matched

but my understanding of your code is limited... sorry if i'm saying useless stuff


Thank's, I think your answer is actually useful, I was not aware of the "design convention" of the delay being minimum 1 sample. I guess that if I want my object to accept

 to it, for which I actually have a conditional.

It is true that it would create an infinite loop when 

, but the only difference with the case where I do not re-read the delay_line after I have written it, is that the input does not go out in the first cycle through the delay_line, it comes a 

 after... Pretty much like as if setting 

. The result is the same after some time: the amplitude might start increasing due to the feedback... I guess that if this behaviour is undesired, I should implement an additional conditional for making 

Thank's, I think your answer is actually useful, I was not aware of the "design convention" of the delay being minimum 1 sample. I guess that if I want my object to acceptdelay=0, I need to re-read the delay_line after I have written the *input++ + (out_sample*feedback) to it, for which I actually have a conditional.

It is true that it would create an infinite loop when feedback!=0, but the only difference with the case where I do not re-read the delay_line after I have written it, is that the input does not go out in the first cycle through the delay_line, it comes a delay_length after... Pretty much like as if setting delay=0, was like setting it to delay=delay_length.  The result is the same after some time: the amplitude might start increasing due to the feedback... I guess that if this behaviour is undesired, I should implement an additional conditional for making feedback=0 when delay=0.


About vdelay~ from "Designing Audio Objects for Max/MSP and Pd"