[long!] delayr/delayw improvements

Date	1999-07-29 14:45
From	Jens Groh
Subject	[long!] delayr/delayw improvements
	Hello, Csounders! Recently, I made some experiments with fed-back delays using delayr, deltap and delayw. But I realized that there are some constraints using delayr/delayw opcode pairs which are avoidable by a source code modification that I made. Let me explain: You can feed back a single delay without problems like in the following example. (There is a minimum delay time of 1 k-rate cycle (1/kr) for delayr.) Example instrument snippet 1: ;------------------------------------------------------------------------- idlytim = ..... kfb = ..... kin = ..... ainput = ..... ; Read delayed signal: adly delayr idlytim ; the delayr instance ; Do some manipulation: afdbk = kfb * adly + kin * ainput ; Feed back signal: delayw afdbk ; associated with the delayr instance out adly ;------------------------------------------------------------------------- When you want to create some cross-feedback of more than one delay, you get a little problem: In order to associate the delayw opcodes with their appropriate delayr opcodes, you have to put them as pairs in the instrument definition. Then there is no way to put the cross-feedback operations at a place where all delayr results are already present in order to calculate all delayw arguments (except the last). Of course, there is a simple solution: Use the feedback values from the previous k-rate cycle! Example instrument snippet 2: ;------------------------------------------------------------------------- idlytim1 = ..... idlytim2 = ..... kfb11 = ..... kfb12 = ..... kfb21 = ..... kfb22 = ..... kin1 = ..... kin2 = ..... ainput1 = ..... ainput2 = ..... afdbk1 init 0.0 afdbk2 init 0.0 ; Read delayed signal: adly1 delayr idlytim1 ; first delayr instance ; Feed back signal of the previous k-rate cycle: delayw afdbk1 ; associated with first delayr instance ; Read delayed signal: adly2 delayr idlytim2 ; second delayr instance ; Feed back signal of the previous k-rate cycle. delayw afdbk2 ; associated with second delayr instance ; Do some cross-coupled manipulation: afdbk1 = kfb11 * adly1 + kfb12 * adly2 + kin1 * ainput1 afdbk2 = kfb21 * adly1 + kfb22 * adly2 + kin2 * ainput2 outs adly1, adly2 ;------------------------------------------------------------------------- BUT! This method adds another 1/kr delay time to the loop. So the minimum delay time value increases to 2/kr. I felt annoyed by that. Wouldn't it be better if one could write it like in the following instrument, without having an additional delay? Example instrument snippet 3: ;------------------------------------------------------------------------- idlytim1 = ..... idlytim2 = ..... kfb11 = ..... kfb12 = ..... kfb21 = ..... kfb22 = ..... kin1 = ..... kin2 = ..... ainput1 = ..... ainput2 = ..... ; Read delayed signal: adly1 delayr idlytim1 ; first delayr instance ; Read delayed signal: adly2 delayr idlytim2 ; second delayr instance ; Do some cross-coupled manipulation: afdbk1 = kfb11 * adly1 + kfb12 * adly2 + kin1 * ainput1 afdbk2 = kfb21 * adly1 + kfb22 * adly2 + kin2 * ainput2 ; Feed back signal of this k-rate cycle: delayw afdbk1 ; associated with first delayr instance ; Feed back signal of this k-rate cycle. delayw afdbk2 ; associated with second delayr instance outs adly1, adly2 ;------------------------------------------------------------------------- But this would not work with current Csound. You cannot interleave the delayr/delayw pairs. To keep the story short, here is the solution: Modify the Csound source code like I did, compile and it should work. Here is the recipe: In file ugens6.h : -------------------------------------------------------------------------- typedef struct { OPDS h; float ar, idlt, istor; float curp; long npts; AUXCH auxch; } DELAYR; -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- typedef struct DELAYR { OPDS h; float ar, idlt, istor; float curp; long npts; AUXCH auxch; struct DELAYR next_delayr; / fifo for delayr pointers by Jens Groh / } DELAYR; -------------------------------------------------------------------------- In file ugens6.c : -------------------------------------------------------------------------- static DELAYR dlrdadr; -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- /* fifo for delayr pointers by Jens Groh: / static DELAYR first_delayr = NULL; /* fifo anchor / static DELAYR last_delayr = NULL; /* fifo anchor / -------------------------------------------------------------------------- In function delrset() in file ugens6.c : -------------------------------------------------------------------------- dlrdadr = p; / store structadr for delayw / -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- / fifo for delayr pointers by Jens Groh: / / append structadr for delayw to fifo: / if (last_delayr != NULL) { / fifo not empty / last_delayr->next_delayr = p; } else { / fifo empty / first_delayr = p; } last_delayr = p; -------------------------------------------------------------------------- In function delwset() in file ugens6.c : -------------------------------------------------------------------------- p->delayr = dlrdadr; / adr delayr struct / -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- / fifo for delayr pointers by Jens Groh: / if (first_delayr == NULL) { initerror("delayw: associated delayr not found"); return; } p->delayr = first_delayr; / adr delayr struct / / remove structadr from fifo / if (last_delayr == first_delayr) { / fifo will be empty / first_delayr = NULL; last_delayr = NULL; } else { / fifo will not be empty / first_delayr = first_delayr->next_delayr; } -------------------------------------------------------------------------- In function tapset() in file ugens6.c : -------------------------------------------------------------------------- p->delayr = dlrdadr; / adr delayr struct / -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- / fifo for delayr pointers by Jens Groh: / if (last_delayr == NULL) { initerror("deltap: associated delayr not found"); return; } p->delayr = last_delayr; / adr delayr struct / -------------------------------------------------------------------------- With it, you can now interleave delayr/delayw pairs. The order of the delayr instances determines the associations with the delayw instances: first delayr - first delayw, second delayr - second delayw, and so on. The number of pairs is not restricted. Any deltap (deltapi, deltapn, deltap3) opcodes still have to be located between the appropriate delayr and delayw. They always refer to the latest preceding delayr instance. Sorry if I bored anyone with the long text. Jens Groh Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11565; 29 Jul 99 14:49 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 119qZ5-0004Zg-00 for jpff@maths.bath.ac.uk; Thu, 29 Jul 1999 14:49:43 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (OAA04580); Thu, 29 Jul 1999 14:45:58 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 29 Jul 1999 14:45:47 +0100 Received: from zit-108.irt.de [194.172.230.108] by hermes via ESMTP (OAA09656); Thu, 29 Jul 1999 14:45:46 +0100 (BST) Received: from pctb151 (pctb151.irt.de [192.168.3.151]) by nett.irt.de (8.9.1/8.9.1) with SMTP id PAA17701; Thu, 29 Jul 1999 15:45:45 +0200 (METDST) Date: Thu, 29 Jul 1999 15:45:45 +0200 (METDST) Message-Id: <199907291345.PAA17701@nett.irt.de> X-Sender: groh@mail X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: csound@maths.ex.ac.uk From: Jens Groh Subject: [long!] delayr/delayw improvements Cc: jpff@maths.bath.ac.uk Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Hello, Csounders! Recently, I made some experiments with fed-back delays using delayr, deltap and delayw. But I realized that there are some constraints using delayr/delayw opcode pairs which are avoidable by a source code modification that I made. Let me explain: You can feed back a single delay without problems like in the following example. (There is a minimum delay time of 1 k-rate cycle (1/kr) for delayr.) Example instrument snippet 1: ;------------------------------------------------------------------------- idlytim = ..... kfb = ..... kin = ..... ainput = ..... ; Read delayed signal: adly delayr idlytim ; the delayr instance ; Do some manipulation: afdbk = kfb adly + kin * ainput ; Feed back signal: delayw afdbk ; associated with the delayr instance out adly ;------------------------------------------------------------------------- When you want to create some cross-feedback of more than one delay, you get a little problem: In order to associate the delayw opcodes with their appropriate delayr opcodes, you have to put them as pairs in the instrument definition. Then there is no way to put the cross-feedback operations at a place where all delayr results are already present in order to calculate all delayw arguments (except the last). Of course, there is a simple solution: Use the feedback values from the previous k-rate cycle! Example instrument snippet 2: ;------------------------------------------------------------------------- idlytim1 = ..... idlytim2 = ..... kfb11 = ..... kfb12 = ..... kfb21 = ..... kfb22 = ..... kin1 = ..... kin2 = ..... ainput1 = ..... ainput2 = ..... afdbk1 init 0.0 afdbk2 init 0.0 ; Read delayed signal: adly1 delayr idlytim1 ; first delayr instance ; Feed back signal of the previous k-rate cycle: delayw afdbk1 ; associated with first delayr instance ; Read delayed signal: adly2 delayr idlytim2 ; second delayr instance ; Feed back signal of the previous k-rate cycle. delayw afdbk2 ; associated with second delayr instance ; Do some cross-coupled manipulation: afdbk1 = kfb11 * adly1 + kfb12 * adly2 + kin1 * ainput1 afdbk2 = kfb21 * adly1 + kfb22 * adly2 + kin2 * ainput2 outs adly1, adly2 ;------------------------------------------------------------------------- BUT! This method adds another 1/kr delay time to the loop. So the minimum delay time value increases to 2/kr. I felt annoyed by that. Wouldn't it be better if one could write it like in the following instrument, without having an additional delay? Example instrument snippet 3: ;------------------------------------------------------------------------- idlytim1 = ..... idlytim2 = ..... kfb11 = ..... kfb12 = ..... kfb21 = ..... kfb22 = ..... kin1 = ..... kin2 = ..... ainput1 = ..... ainput2 = ..... ; Read delayed signal: adly1 delayr idlytim1 ; first delayr instance ; Read delayed signal: adly2 delayr idlytim2 ; second delayr instance ; Do some cross-coupled manipulation: afdbk1 = kfb11 * adly1 + kfb12 * adly2 + kin1 * ainput1 afdbk2 = kfb21 * adly1 + kfb22 * adly2 + kin2 * ainput2 ; Feed back signal of this k-rate cycle: delayw afdbk1 ; associated with first delayr instance ; Feed back signal of this k-rate cycle. delayw afdbk2 ; associated with second delayr instance outs adly1, adly2 ;------------------------------------------------------------------------- But this would not work with current Csound. You cannot interleave the delayr/delayw pairs. To keep the story short, here is the solution: Modify the Csound source code like I did, compile and it should work. Here is the recipe: In file ugens6.h : -------------------------------------------------------------------------- typedef struct { OPDS h; float ar, idlt, istor; float curp; long npts; AUXCH auxch; } DELAYR; -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- typedef struct DELAYR { OPDS h; float ar, idlt, istor; float curp; long npts; AUXCH auxch; struct DELAYR next_delayr; / fifo for delayr pointers by Jens Groh / } DELAYR; -------------------------------------------------------------------------- In file ugens6.c : -------------------------------------------------------------------------- static DELAYR dlrdadr; -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- /* fifo for delayr pointers by Jens Groh: / static DELAYR first_delayr = NULL; /* fifo anchor / static DELAYR last_delayr = NULL; /* fifo anchor / -------------------------------------------------------------------------- In function delrset() in file ugens6.c : -------------------------------------------------------------------------- dlrdadr = p; / store structadr for delayw / -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- / fifo for delayr pointers by Jens Groh: / / append structadr for delayw to fifo: / if (last_delayr != NULL) { / fifo not empty / last_delayr->next_delayr = p; } else { / fifo empty / first_delayr = p; } last_delayr = p; -------------------------------------------------------------------------- In function delwset() in file ugens6.c : -------------------------------------------------------------------------- p->delayr = dlrdadr; / adr delayr struct / -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- / fifo for delayr pointers by Jens Groh: / if (first_delayr == NULL) { initerror("delayw: associated delayr not found"); return; } p->delayr = first_delayr; / adr delayr struct / / remove structadr from fifo / if (last_delayr == first_delayr) { / fifo will be empty / first_delayr = NULL; last_delayr = NULL; } else { / fifo will not be empty / first_delayr = first_delayr->next_delayr; } -------------------------------------------------------------------------- In function tapset() in file ugens6.c : -------------------------------------------------------------------------- p->delayr = dlrdadr; / adr delayr struct / -------------------------------------------------------------------------- is replaced by : -------------------------------------------------------------------------- / fifo for delayr pointers by Jens Groh: / if (last_delayr == NULL) { initerror("deltap: associated delayr not found"); return; } p->delayr = last_delayr; / adr delayr struct */ -------------------------------------------------------------------------- With it, you can now interleave delayr/delayw pairs. The order of the delayr instances determines the associations with the delayw instances: first delayr - first delayw, second delayr - second delayw, and so on. The number of pairs is not restricted. Any deltap (deltapi, deltapn, deltap3) opcodes still have to be located between the appropriate delayr and delayw. They always refer to the latest preceding delayr instance. Sorry if I bored anyone with the long text. Jens Groh Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12340; 29 Jul 99 18:27 BST Received: from [194.179.21.2] (helo=lix.intercom.es ident=root) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 119szi-0006Mk-00 for jpff@maths.bath.ac.uk; Thu, 29 Jul 1999 17:25:23 +0100 Received: from intercom.es (iv3-87.intercom.es [195.76.131.87]) by lix.intercom.es (8.7.3/8.6.12) with ESMTP id TAA19507; Thu, 29 Jul 1999 19:32:37 +0100 Message-ID: <37A089D0.B6917AAE@intercom.es> Date: Thu, 29 Jul 1999 19:05:20 +0200 From: Josep M Comajuncosas X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: Jens Groh CC: csound@maths.ex.ac.uk, jpff@maths.bath.ac.uk Subject: Re: [long!] delayr/delayw improvements References: <199907291345.PAA17701@nett.irt.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jens Groh wrote: > Recently, I made some experiments with fed-back delays using delayr, deltap > and delayw. > But I realized that there are some constraints using delayr/delayw opcode > pairs which are avoidable by a source code modification that I made That looks absolutely great! It can be extremely useful for some waveguide modelling stuff also, and for designing complex reverberators. Maybe a way to direct delayw to a given delayr likeasig delayr idltm, itarget delayw asig,idelayr_target (where idelayr_target refers to a delayr, sort of hyperlink) would make things more clear and the order of the delayw opcodes wouldnt imply their assignation to a given delayr (I find this rather messy)... maybe there are better solutions. I hope I will be added to the sources soon. Josep M -- Josep M Comajuncosas C/ Circumval.lacio 75 08790 Gelida - Penedes Catalunya - SPAIN tel. 93 7792243 e-mail: gelida@intercom.es ET Informatica de Sistemes e-mail: jcomajuncosas@campus.uoc.es http://members.tripod.com/csound/ Received: from shaun.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12350; 29 Jul 99 18:30 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by shaun.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 119u0m-0004fR-00 for jpff@maths.bath.ac.uk; Thu, 29 Jul 1999 18:30:32 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (SAA05162); Thu, 29 Jul 1999 18:27:09 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Thu, 29 Jul 1999 18:27:02 +0100 Received: from root@lix.intercom.es [194.179.21.2] by hermes via ESMTP (SAA12540); Thu, 29 Jul 1999 18:26:53 +0100 (BST) Received: from intercom.es (iv3-87.intercom.es [195.76.131.87]) by lix.intercom.es (8.7.3/8.6.12) with ESMTP id TAA19507; Thu, 29 Jul 1999 19:32:37 +0100 Message-ID: <37A089D0.B6917AAE@intercom.es> Date: Thu, 29 Jul 1999 19:05:20 +0200 From: Josep M Comajuncosas X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: Jens Groh CC: csound@maths.ex.ac.uk, jpff@maths.bath.ac.uk Subject: Re: [long!] delayr/delayw improvements References: <199907291345.PAA17701@nett.irt.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by exeter.ac.uk id SAA12540 Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk Jens Groh wrote: > Recently, I made some experiments with fed-back delays using delayr, de= ltap > and delayw. > But I realized that there are some constraints using delayr/delayw opco= de > pairs which are avoidable by a source code modification that I made That looks absolutely great! It can be extremely useful for some waveguid= e modelling stuff also, and for designing complex reverberators. Maybe a wa= y to direct delayw to a given delayr likeasig delayr idltm, itarget delayw asig,idelayr_target (where idelayr_target refers to a delayr, sor= t of hyperlink) would make things more clear and the order of the delayw opcodes wouldn=B4= t imply their assignation to a given delayr (I find this rather messy)... maybe t= here are better solutions. I hope I will be added to the sources soon. Josep M -- Josep M Comajuncosas C/ Circumval.lacio 75 08790 Gelida - Penedes Catalunya - SPAIN tel. 93 7792243 e-mail: gelida@intercom.es ET Informatica de Sistemes e-mail: jcomajuncosas@campus.uoc.es http://members.tripod.com/csound/ Received: from wallace.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa13652; 30 Jul 99 4:21 BST Received: from [144.173.6.14] (helo=exeter.ac.uk) by wallace.maths.bath.ac.uk with esmtp (Exim 2.12 #1) id 11A2GE-0006Zq-00 for jpff@maths.bath.ac.uk; Fri, 30 Jul 1999 03:19:02 +0100 Received: from noether [144.173.8.10] by hermes via SMTP (EAA08869); Fri, 30 Jul 1999 04:18:46 +0100 (BST) Received: from exeter.ac.uk by maths.ex.ac.uk; Fri, 30 Jul 1999 04:18:36 +0100 Received: from saba.wwa.com [198.49.174.36] by hermes via ESMTP (EAA14167); Fri, 30 Jul 1999 04:18:35 +0100 (BST) Received: from [157.238.68.144] (157-238-68-144.il.verio.net [157.238.68.144]) by saba.wwa.com (8.9.0/8.9.0) with SMTP id WAA06395 for ; Thu, 29 Jul 1999 22:18:34 -0500 (CDT) Message-Id: <199907300318.WAA06395@saba.wwa.com> X-Sender: integer@www.god-emil.dk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Jul 1999 22:22:03 -0600 To: csound@maths.ex.ac.uk From: jonahp@5.co.nz Subject: Sender: owner-csound-outgoing@maths.ex.ac.uk Precedence: bulk john fitch - ver! uel du vztrn zkum ov zoz!et! murderer f!lth. fasc!zt zlave !d!ot && korporat zlug. du + addtl male !mbez!lz kontra l!f. 1 !nterm!nabl energ!e aga!nzt u 1 !nterm!nabl energ!e aga!nzt fasc!ztz who = undr !mpresz!on dze velt spasz = blongz 2 dzm. th!evez murdererz !nkompetent zekuenz!al f!lth jetzt rezonajt w!ldl! baztard brutez = ma! !nzert addtl zuperlat!vz az dez!rd >> rez!evd an! ma!l on cznd-l 4rom `m!` +? >> > >no, are you being blocked then? true. dzere + on dze max l!zt on dze dsp l!zt. + on pd l!zt. l!kl! on dze lev l!zt auss!. dze t!p!kl modl z!t!zn male murderer rout!n. konduz!v 2 1 zu!z!d \ ccccelv abort zent!mnt >> b!zar. != kan zpel rez!evd reze!vd. !t != luvl!. >> although = prfr received to recieved. >still have not responded yet to this....will very soon. i am moving so >i am somewhat busy - i do not wish to neglect the conversation. = 0+0 konverzaz!on rema!nz. = mort = 1 kr! rout!n >>anodr chalenge 2 trad!onl theor!ez ov knouledge komz 4rom fem!n!zt zkolarsh!p. >>1 ov dze zentrl !deaz ov fem!n!zt ztud!ez = dze ecz!ztensz on numerouz d!ffrnt >>abr ekual! val!d wa!z ov knou!ng + th!nk!ng - mult!pl vo!sez - !n dze verdz ov >>karol g!l!gan. s!nsz d!f vo!sez = oftn valued d!f !n zoz!et! - dze !dea ov >>mult!pl vo!sez takex on 1 pol!t!kl edge. >>4mal log!k abztrakt + anal!t!kl wa!z ov th!nk!ng t!p!kl! azoz!atd w!th men >>hav b!n pr!v!ledged. - v!eud az zuper!or. mor advanszd. mor l!kl! 2 lead 2 >>`truth`. on dze odr hand relaz!onl + kontecztual ua!z ov th!nk!ng t!p!kl! >>azoz!atd w!th women hav b!n undrvalued + d!zkouraged. >> >>relaz!onl + kontecztual ua!z ov th!nk!ng = off top!k >>!f natur operatd az d!esz l!ztz ___.. >> >>!t = 1 !mposz!b!l!t!. = 0+0 l!f 4rm kan b egot!zt!kl >>az = 0+0 l!f 4rm kan ecz!zt zanz akz!onz. >>all akz!onz = !nter akz!onz __... >> >>dze zelf!sh gene != kan ecz!zt.