Nikolas Valsamakis

I'm trying to make a feedback delay patch using the cycling buffer technique with two pointers, one that writes and one that reads.The patch works perfect as long as it's a simple delay. The problem arises when I'm trying to include a feedback option. Please check the attached patch. In this you can set the maximum delay as well as the current delay (both in samples). Since it is not a straight feedback connection that it is known that does not work in msp, do you have any idea on this dysfunctional behavior???

feedback-using-poke-index-in-a-cycling-buffer-delay

> I'm trying to make a feedback delay patch using the cycling buffer

> technique with two pointers, one that writes and one that reads.The

> patch works perfect as long as it's a simple delay. The problem

> arises when I'm trying to include a feedback option. Please check the

> attached patch. In this you can set the maximum delay as well as the

> current delay (both in samples). Since it is not a straight feedback

> connection that it is known that does not work in msp, do you have

> any idea on this dysfunctional behavior???

It's actually the same technique which is used in tapin~/tapout~. Its 

the nature of the DSP chain, if you do a feedback like that, which is 

allowed, it will introduce a signal vector delay. You can't avoid it.

At the point of the feedback you have access only to the last signal 

vector, the new value isn't written yet...

Only two possibilities, comb~, or write your own external in C...

Nikolas Valsamakis schrieb:
> I'm trying to make a feedback delay patch using the cycling buffer
> technique with two pointers, one that writes and one that reads.The
> patch works perfect as long as it's a simple delay. The problem
> arises when I'm trying to include a feedback option. Please check the
> attached patch. In this you can set the maximum delay as well as the
> current delay (both in samples). Since it is not a straight feedback
> connection that it is known that does not work in msp, do you have
> any idea on this dysfunctional behavior???

;-) I tried the same ;-)
It's actually the same technique which is used in tapin~/tapout~. Its 
the nature of the DSP chain, if you do a feedback like that, which is 
allowed, it will introduce a signal vector delay. You can't avoid it.

At the point of the feedback you have access only to the last signal 
vector, the new value isn't written yet...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


There is literally no way of generally doing a sub dsp-vector delay 

scheme that will allow you to feed back into the input of the delay 

object eventually. Imagine a hypothetical C object that could do 

this. Certainly there's no way to get data into another object and 

then back into the hypothetical delay object's input without 

With a 32 frame vector, we're talking just over .5ms as the minimum 

delay that will allow feedback, perhaps not good enough for feedback 

FM synthesis. For that, I completely agree with Stefan: you'll have 

On May 23, 2007, at 10:35 PM, Stefan Tiedje wrote:

>> I'm trying to make a feedback delay patch using the cycling buffer

>> technique with two pointers, one that writes and one that reads.The

>> patch works perfect as long as it's a simple delay. The problem

>> arises when I'm trying to include a feedback option. Please check the

>> attached patch. In this you can set the maximum delay as well as the

>> current delay (both in samples). Since it is not a straight feedback

>> connection that it is known that does not work in msp, do you have

>> any idea on this dysfunctional behavior???

> It's actually the same technique which is used in tapin~/tapout~. 

> Its the nature of the DSP chain, if you do a feedback like that, 

> which is allowed, it will introduce a signal vector delay. You 

> At the point of the feedback you have access only to the last 

> signal vector, the new value isn't written yet...

> Only two possibilities, comb~, or write your own external in C...

There is literally no way of generally doing a sub dsp-vector delay  
scheme that will allow you to feed back into the input of the delay  
object eventually.  Imagine a hypothetical C object that could do  
this.  Certainly there's no way to get data into another object and  
then back into the hypothetical delay object's input without  
subverting the DSP chain.

With a 32 frame vector, we're talking just over .5ms as the minimum  
delay that will allow feedback, perhaps not good enough for feedback  
FM synthesis.  For that, I completely agree with Stefan: you'll have  
to roll your own in C.

> Nikolas Valsamakis schrieb:
>> I'm trying to make a feedback delay patch using the cycling buffer
>> technique with two pointers, one that writes and one that reads.The
>> patch works perfect as long as it's a simple delay. The problem
>> arises when I'm trying to include a feedback option. Please check the
>> attached patch. In this you can set the maximum delay as well as the
>> current delay (both in samples). Since it is not a straight feedback
>> connection that it is known that does not work in msp, do you have
>> any idea on this dysfunctional behavior???
>
> ;-) I tried the same ;-)
> It's actually the same technique which is used in tapin~/tapout~.  
> Its the nature of the DSP chain, if you do a feedback like that,  
> which is allowed, it will introduce a signal vector delay. You  
> can't avoid it.
>
> At the point of the feedback you have access only to the last  
> signal vector, the new value isn't written yet...
>
> Only two possibilities, comb~, or write your own external in C...
>
> Stefan
>
> -- 
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>


It's also possible to use poly~ with a vector size of 1 sample (since 

It's also possible to use poly~ with a vector size of 1 sample (since  
4.6.3).

Mark Pauley wrote on Thu, 24 May 2007 11:48

> For that, I completely agree with Stefan: you'll have 

yes thats an option. But it excludes all the interesting possibilities of inserting various other proccesses within the feedback loop (which was the initial goal of my simple feedback delay prototype)...

Emmanuel Jourdan wrote on Thu, 24 May 2007 12:49

> It's also possible to use poly~ with a vector size of 1 sample (since 4.6.3).

yes, this is a more realistic option concerning time/flexibility but it easily explodes the cpu...

maybe supercollider is more efficient in microlevel processes...

Mark Pauley wrote on Thu, 24 May 2007 11:48
> For that, I completely agree with Stefan: you'll have  
> to roll your own in C.

Emmanuel Jourdan wrote on Thu, 24 May 2007 12:49
> It's also possible to use poly~ with a vector size of 1 sample (since  4.6.3).

feedback using poke~ & index~ in a cycling buffer delay