Hi,
Can somebody please explain how nested delays works in csound? I thought 
that when nesting delay lines delayw would write to the immediately 
preceding delay line so that this would give crossing feedback (L-R 
ping-pong) between the delay lines: 
   
    adel1 delayr idelt
    adel2 delayr idelt

    afeed1 = a1 + (adel1 * ifeed)
    afeed2 = a2 + (adel2 * ifeed)

    delayw afeed1
    delayw afeed2

However, I have to change the order of the delayw's to get crossing 
feedback:
   
    adel1 delayr idelt
    adel2 delayr idelt

    afeed1 = a1 + (adel1 * ifeed)
    afeed2 = a2 + (adel2 * ifeed)

    delayw afeed2
    delayw afeed1

Have I completely misunderstood, or have I missed something crucial here?

I have posted a simple csd that I used when testing this.

Best,
Andreas


-- 
Andreas Bergsland,
universitetslektor / PhD-kandidat

Musikkteknologiseksjonen
Institutt for musikk
Olavskvartalet
NTNU
7491 Trondheim

Besøksadresse: Fjordgt.1 (3.etg.)
e-post: andreas.bergsland@hf.ntnu.no
Tlf: 7359 0096
Mob: 4566 3316

Chapt 24 of The Csound Book, "Implementing the 
Gardner Reverbs in Csound" by Hans Mikelson is an 
excellent exploration of nested delays.

--David

At 04:20 AM 4/30/2009, you wrote:
>Hi,
>Can somebody please explain how nested delays 
>works in csound? I thought that when nesting 
>delay lines delayw would write to the 
>immediately preceding delay line so that this 
>would give crossing feedback (L-R ping-pong) between the delay lines:
>    adel1 delayr idelt
>    adel2 delayr idelt
>
>    afeed1 = a1 + (adel1 * ifeed)
>    afeed2 = a2 + (adel2 * ifeed)
>
>    delayw afeed1
>    delayw afeed2
>
>However, I have to change the order of the delayw's to get crossing feedback:
>
>    adel1 delayr idelt
>    adel2 delayr idelt
>
>    afeed1 = a1 + (adel1 * ifeed)
>    afeed2 = a2 + (adel2 * ifeed)
>
>    delayw afeed2
>    delayw afeed1
>
>Have I completely misunderstood, or have I missed something crucial here?
>
>I have posted a simple csd that I used when testing this.
>
>Best,
>Andreas
>
>
>--
>Andreas Bergsland,
>universitetslektor / PhD-kandidat
>
>Musikkteknologiseksjonen
>Institutt for musikk
>Olavskvartalet
>NTNU
>7491 Trondheim
>
>Besøksadresse: Fjordgt.1 (3.etg.)
>e-post: andreas.bergsland@hf.ntnu.no
>Tlf: 7359 0096
>Mob: 4566 3316
>
>
>Send bugs reports to this list.
>To unsubscribe, send email 
>sympa@lists.bath.ac.uk with body "unsubscribe csound"
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
>
>
>
>
>
>
>         sr     = 44100
>         kr     = 4410
>         ksmps  = 10
>         nchnls = 2
>
>instr   1
>kenv1   linseg  1, 1, 0
>kenv2   linseg  0, .2, 1, .2, 0
>
>a1      oscils  5000, 550, 0
>a1      =       a1*kenv1
>
>a2      rand    5000
>a2      =       a2*kenv2
>
>ifeed   =       .5
>idelt   =       .5
>
>     adel1 delayr idelt
>     adel2 delayr idelt
>
>     afeed1 = a1 + (adel1 * ifeed)
>     afeed2 = a2 + (adel2 * ifeed)
>
>     delayw afeed2
>     delayw afeed1
>
>outs    adel1, adel2
>endin
>
>
>
>i1      0       8
>
>

Maxine Heller: mheller@city-net.com
David Mooney: dmooney@city-net.com
www.city-net.com/~moko/ 

David Mooney/Maxine Heller wrote:
> Chapt 24 of The Csound Book, "Implementing the Gardner Reverbs in 
> Csound" by Hans Mikelson is an excellent exploration of nested delays.

No it isn't because it assumes sr=kr and so doesn't address 
the OP's problem at all.  I've tried to convert the examples 
to use delayr/w and found it they didn't seem to nest properly.

Assurances on the list were all that it delayr/w were 
working fine, and that you could have multiple delay lines 
by nesting them.  Now, Andreas has come up with a minimal 
example that he says is inconsistent with that advertised 
behavior.  Nobody has contradicted him.  Is it time to say 
that delayr/w don't nest after all?

The official solution seems to be to forget efficiency and 
set sr=kr.  With a local ksmps in a UDO that might even be 
good enough for real-time performance.  It wasn't an option 
when The Csound Book was written, and so isn't covered there.


                 Graham

I understand the sr=kr objection and the OP's problem with delayr/w, 
but if realtime is not an issue, the nested allpass filters that 
Mikelson describes are powerful and flexible. These use the delay 
opcode, not delayr/w.

--David

At 09:21 PM 5/1/2009, you wrote:
>David Mooney/Maxine Heller wrote:
>>Chapt 24 of The Csound Book, "Implementing the Gardner Reverbs in 
>>Csound" by Hans Mikelson is an excellent exploration of nested delays.
>
>No it isn't because it assumes sr=kr and so doesn't address the OP's 
>problem at all.  I've tried to convert the examples to use delayr/w 
>and found it they didn't seem to nest properly.
>
>Assurances on the list were all that it delayr/w were working fine, 
>and that you could have multiple delay lines by nesting them.  Now, 
>Andreas has come up with a minimal example that he says is 
>inconsistent with that advertised behavior.  Nobody has contradicted 
>him.  Is it time to say that delayr/w don't nest after all?
>
>The official solution seems to be to forget efficiency and set 
>sr=kr.  With a local ksmps in a UDO that might even be good enough 
>for real-time performance.  It wasn't an option when The Csound Book 
>was written, and so isn't covered there.
>
>
>                 Graham
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>"unsubscribe csound"

Maxine Heller: mheller@city-net.com
David Mooney: dmooney@city-net.com
www.city-net.com/~moko/ 

There is also the nested opcode to explore.

-dB

================================================
   Dr. Richard Boulanger
   Professor of Electronic Production and Design
   Music Technology Division
   Berklee College of Music
   1140 Boylston Street
   Boston, MA 02135
   rboulanger@berklee.edu
   http://csounds.com/boulanger
   617-747-2485 (office)
=================================================

On May 1, 2009, at 9:21 PM, Graham Breed wrote:

> David Mooney/Maxine Heller wrote:
>> Chapt 24 of The Csound Book, "Implementing the Gardner Reverbs in  
>> Csound" by Hans Mikelson is an excellent exploration of nested  
>> delays.
>
> No it isn't because it assumes sr=kr and so doesn't address the OP's  
> problem at all.  I've tried to convert the examples to use delayr/w  
> and found it they didn't seem to nest properly.
>
> Assurances on the list were all that it delayr/w were working fine,  
> and that you could have multiple delay lines by nesting them.  Now,  
> Andreas has come up with a minimal example that he says is  
> inconsistent with that advertised behavior.  Nobody has contradicted  
> him.  Is it time to say that delayr/w don't nest after all?
>
> The official solution seems to be to forget efficiency and set  
> sr=kr.  With a local ksmps in a UDO that might even be good enough  
> for real-time performance.  It wasn't an option when The Csound Book  
> was written, and so isn't covered there.
>
>
>                Graham
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Ok, what I understand from  your answers is that this question has an 
history, but since I haven't been constantly on the list for the last 
few years I am not able to read so much between the lines here. But what 
it boils down for me is that I had a student that confronted me with 
this behaviour and I didn't know how to answer him.
Is the answer that this is some kind of bug, or simply that you have to 
use a different approach (e.g. the delay opcode) to do nested delays?
BTW I tried my simple example with kr=sr with no change.
Best regards, Andreas
> I understand the sr=kr objection and the OP's problem with delayr/w, 
> but if realtime is not an issue, the nested allpass filters that 
> Mikelson describes are powerful and flexible. These use the delay 
> opcode, not delayr/w.
>
> --David
>
> At 09:21 PM 5/1/2009, you wrote:
>> David Mooney/Maxine Heller wrote:
>>> Chapt 24 of The Csound Book, "Implementing the Gardner Reverbs in 
>>> Csound" by Hans Mikelson is an excellent exploration of nested delays.
>>
>> No it isn't because it assumes sr=kr and so doesn't address the OP's 
>> problem at all.  I've tried to convert the examples to use delayr/w 
>> and found it they didn't seem to nest properly.
>>
>> Assurances on the list were all that it delayr/w were working fine, 
>> and that you could have multiple delay lines by nesting them.  Now, 
>> Andreas has come up with a minimal example that he says is 
>> inconsistent with that advertised behavior.  Nobody has contradicted 
>> him.  Is it time to say that delayr/w don't nest after all?
>>
>> The official solution seems to be to forget efficiency and set 
>> sr=kr.  With a local ksmps in a UDO that might even be good enough 
>> for real-time performance.  It wasn't an option when The Csound Book 
>> was written, and so isn't covered there.
>>
>>
>>                 Graham
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> "unsubscribe csound"
>
> Maxine Heller: mheller@city-net.com
> David Mooney: dmooney@city-net.com
> www.city-net.com/~moko/
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
> "unsubscribe csound"


-- 
Andreas Bergsland,
universitetslektor / PhD-kandidat

Musikkteknologiseksjonen
Institutt for musikk
Olavskvartalet
NTNU
7491 Trondheim

Besøksadresse: Fjordgt.1 (3.etg.)
e-post: andreas.bergsland@hf.ntnu.no
Tlf: 7359 0096
Mob: 4566 3316

Can't really help you with the history--never 
tried nesting using delayr/w, just know from 
comments that there seems to be some issue with 
it. The delay opcode does work.

--David

At 04:37 AM 5/3/2009, you wrote:
>Ok, what I understand from  your answers is that 
>this question has an history, but since I 
>haven't been constantly on the list for the last 
>few years I am not able to read so much between 
>the lines here. But what it boils down for me is 
>that I had a student that confronted me with 
>this behaviour and I didn't know how to answer him.
>Is the answer that this is some kind of bug, or 
>simply that you have to use a different approach 
>(e.g. the delay opcode) to do nested delays?
>BTW I tried my simple example with kr=sr with no change.
>Best regards, Andreas
>>I understand the sr=kr objection and the OP's 
>>problem with delayr/w, but if realtime is not 
>>an issue, the nested allpass filters that 
>>Mikelson describes are powerful and flexible. 
>>These use the delay opcode, not delayr/w.
>>
>>--David
>>
>>At 09:21 PM 5/1/2009, you wrote:
>>>David Mooney/Maxine Heller wrote:
>>>>Chapt 24 of The Csound Book, "Implementing 
>>>>the Gardner Reverbs in Csound" by Hans 
>>>>Mikelson is an excellent exploration of nested delays.
>>>
>>>No it isn't because it assumes sr=kr and so 
>>>doesn't address the OP's problem at all.  I've 
>>>tried to convert the examples to use delayr/w 
>>>and found it they didn't seem to nest properly.
>>>
>>>Assurances on the list were all that it 
>>>delayr/w were working fine, and that you could 
>>>have multiple delay lines by nesting 
>>>them.  Now, Andreas has come up with a minimal 
>>>example that he says is inconsistent with that 
>>>advertised behavior.  Nobody has contradicted 
>>>him.  Is it time to say that delayr/w don't nest after all?
>>>
>>>The official solution seems to be to forget 
>>>efficiency and set sr=kr.  With a local ksmps 
>>>in a UDO that might even be good enough for 
>>>real-time performance.  It wasn't an option 
>>>when The Csound Book was written, and so isn't covered there.
>>>
>>>
>>>                 Graham
>>>
>>>
>>>Send bugs reports to this list.
>>>To unsubscribe, send email 
>>>sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>Maxine Heller: mheller@city-net.com
>>David Mooney: dmooney@city-net.com
>>www.city-net.com/~moko/
>>
>>
>>Send bugs reports to this list.
>>To unsubscribe, send email 
>>sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>--
>Andreas Bergsland,
>universitetslektor / PhD-kandidat
>
>Musikkteknologiseksjonen
>Institutt for musikk
>Olavskvartalet
>NTNU
>7491 Trondheim
>
>Besøksadresse: Fjordgt.1 (3.etg.)
>e-post: andreas.bergsland@hf.ntnu.no
>Tlf: 7359 0096
>Mob: 4566 3316
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email 
>sympa@lists.bath.ac.uk with body "unsubscribe csound"

Maxine Heller: mheller@city-net.com
David Mooney: dmooney@city-net.com
www.city-net.com/~moko/