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

May 23, 2007 at 6:08pm

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

Hello there!!!

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???

thanks,

Nikolas

max v2;
#N vpatcher 10 59 973 733;
#P origin -74 52;
#P window setfont “Sans Serif” 9.;
#P comment 428 99 373 196617 5) compare the two waveform displays. Why it doesn’t work propertly :-(;
#P comment 428 84 161 196617 4) turn on/off the DAC again;
#P comment 428 56 191 196617 2) compare the two waveform displays;
#P window setfont “Sans Serif” 14.;
#P comment 37 78 103 196622 …to there ->;
#B color 15;
#P user panel 29 74 118 29;
#X brgb 255 252 25;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P window setfont “Sans Serif” 9.;
#P comment 210 64 118 196617 feedback level (0. – 1.);
#P newex 106 252 48 196617 loadbang;
#P user number~ 168 61 207 76 9 3 3 1 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P user number~ 164 133 203 148 9 3 3 2 0. 0. 0 0. 250 0. 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 647 145 66 196617 loadmess 25;
#P newex 219 82 48 196617 loadbang;
#P newex 151 89 27 196617 *~;
#P newex 134 114 27 196617 +~;
#P newex 77 111 39 196617 noise~;
#P newex 335 270 265 196617 poke~ display;
#P message 106 370 56 196617 set display;
#P newex 335 240 85 196617 index~ delaybuff;
#P window linecount 2;
#P comment 389 139 47 196617 delay in samps;
#P number 352 139 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 335 176 27 196617 -~;
#P newex 273 82 90 196617 receive maxdelay;
#P newex 365 176 90 196617 receive maxdelay;
#P newex 733 200 76 196617 send maxdelay;
#P newex 335 208 69 196617 pong~ 1 0 25;
#P number 647 169 58 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 647 200 79 196617 sizeinsamps $1;
#P newex 219 105 64 196617 count~ 0 25;
#P message 115 281 69 196617 set delaybuff;
#P newex 558 222 88 196617 buffer~ display 1;
#P newex 647 222 98 196617 buffer~ delaybuff 1;
#P newex 134 167 180 196617 poke~ delaybuff;
#P user ezdac~ 528 138 572 171 0;
#P window linecount 2;
#P comment 714 163 56 196617 max delay (in samps);
#P window linecount 1;
#P comment 89 136 47 196617 signal in;
#P user waveform~ 233 410 471 99 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit samples;
#W grid 22.675737;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P user waveform~ 233 313 471 99 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit samples;
#W grid 22.675737;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P window setfont “Sans Serif” 14.;
#P comment 163 246 171 196622 connect from here… ->;
#B color 15;
#P user panel 155 242 177 27;
#X brgb 255 252 25;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P window setfont “Sans Serif” 9.;
#P comment 428 70 250 196617 3) connect the [index~] outlet to the [*~] left inlet.;
#P comment 428 41 161 196617 1) turn on/off the DAC;
#P connect 33 0 24 0;
#P fasten 33 0 12 0 111 273 120 273;
#P fasten 26 0 27 0 82 130 125 130 125 107 139 107;
#P connect 27 0 9 0;
#P connect 28 0 27 1;
#P connect 28 0 31 0;
#P connect 32 0 28 1;
#P connect 29 0 13 0;
#P connect 13 0 9 1;
#P fasten 12 0 4 0 120 304 238 304;
#P fasten 24 0 5 0 111 399 238 399;
#P connect 19 0 13 1;
#P fasten 13 0 20 0 224 130 340 130;
#P connect 20 0 16 0;
#P connect 16 0 23 0;
#P connect 23 0 25 0;
#P connect 21 0 20 1;
#P fasten 18 0 16 2 370 200 398 200;
#P fasten 13 0 25 1 224 130 467 130;
#P fasten 14 0 11 0 652 219 563 219;
#P connect 30 0 15 0;
#P connect 15 0 14 0;
#P connect 14 0 10 0;
#P fasten 5 5 4 4 698 519 713 519 713 301 698 301;
#P connect 4 5 5 4;
#P fasten 15 0 17 0 652 192 738 192;
#P pop;

#32052
May 24, 2007 at 5:35am

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

#104854
May 24, 2007 at 8:48am

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.

_Mark

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

> 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
>

#104855
May 24, 2007 at 9:49am

Hi,

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

ej

#104856
May 24, 2007 at 10:54am

Thank you all for your responses!

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.

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…

nikolas

#104857

You must be logged in to reply to this topic.