From: owner-sc-users-digest@lists.io.com (sc-users-digest) To: sc-users-digest@lists.io.com Subject: sc-users-digest V1 #354 Reply-To: sc-users Sender: owner-sc-users-digest@lists.io.com Errors-To: owner-sc-users-digest@lists.io.com Precedence: bulk sc-users-digest Monday, September 10 2001 Volume 01 : Number 354 ---------------------------------------------------------------------- Date: Sat, 08 Sep 2001 16:17:56 -0400 From: "crucial" <---@---.---> Subject: [ot] lisp vs. java and c++ of interest to people into unfortunately obscure languages: http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html "Our results show that Lisp's performance is comparable to or better than C++ in terms of execution speed, with significantly lower variability which translates into reduced project risk. Furthermore, development time is significantly lower and less variable than either C++ or Java. Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java for dynamic applications where performance is important. " _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Sat, 08 Sep 2001 21:09:23 -0400 From: christian adam hresko <---@---.---> Subject: Re: [ot] lisp vs. java and c++ crucial wrote: > of interest to people into unfortunately obscure languages: > > http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html > > "Our results show that Lisp's performance is > comparable to or better than C++ in terms of execution speed, with significantly lower > variability which translates into > reduced project risk. Furthermore, development time is significantly lower and less > variable than either C++ or Java. > Memory consumption is comparable to Java. Lisp thus presents a viable alternative to Java > for dynamic applications where > performance is important. " > what do you mean by unfortunately obscure? do you mean it's unfortunate that one programs in Lisp, or that it's unfortunate that Lisp isn't as 'popular' as C++ or Java? all bees love flowers only, christian ------------------------------ Date: Sat, 08 Sep 2001 21:29:56 -0700 From: cramakrishnan@acm.org Subject: Re: [ot] lisp vs. java and c++ "crucial" writes: > "Our results show that Lisp's performance is comparable to or better > than C++ in terms of execution speed, with significantly lower > variability which translates into reduced project risk. Furthermore, > development time is significantly lower and less variable than > either C++ or Java. Memory consumption is comparable to Java. Lisp > thus presents a viable alternative to Java for dynamic applications > where performance is important. " As we used to say in the good ol' days: C runs faster, Smalltalk runs first. I've always understood that statement as having two meanings... - - sekhar - -- C. Ramakrishnan cramakrishnan@acm.org ------------------------------ Date: Sun, 9 Sep 2001 13:31:34 -0400 From: Phil C <---@---.---> Subject: Some requests... (sorry if the list already received this email, I have not seen it yet??) Hello... Before the ideas, comments requests ... I have two quick questions... 1) What are the available sequencing classes in SC? I have tried to find more than OrcScore and ImpulseSequencer and had no luck. I am not looking in the right place? (Help.help, online...) If someone could let me know I would be ever so greatful... 2) Why is the documentation for View/GUIWindow so lacking? I have managed to get some pretty cool stuff done thus far with the GUI's but that was all through reading code... Are there any comprehensive docs out there? I am building a step sequencer GUI ... and want to be able to control, within my code, what objects can be .focus'ed. While I have modified View.sc and changed .canFocus to a getter/setter, I was wondering if this could be 'professionally' done... ie integrated somehow into SC2.2.12 or something... Oh and just in case those of you in the 'know' are wondering, I also updated StringView and MeterView to reflect the newly defined method of .canFocus. Unfortunately, with MeterView I was not sure how exactly to 'fix' it since it does not have any direct instantiation method (inherits it from ControlView ???)... Anyway, I have been playing with it and it works... now when I tab in the GUI of a total of 126 .focus'able (.canFocus used to return true for all of them) only 20 of them .canFocus now. :) Next, something down the road for the OS X version of SC3... A command line version of SC, which would allow vi/vim freaks like myself to use our beloved editor to code SC. I was thinking about this and being the vi/vim is open source those interested could hack said editor(s) to add special key bindings or something to use the command line version to send signals or something to the SC virtual machine ... that way you could still have the lovely access to help, code pop-ups etc. Setting up a command line version would also allow us to run code from vi, doing the whole :! bit and if you use vim also have syntax high lighting. >:} // devilish smirk I may be stepping out of line here, but I continued to think about a possible solution to how you could get around communicating with the VM. Obviously, it would be a bad thing if you had more than one open at a time, resources and what not. So, to be able to use the command line version you would have to start up the OS X full blown .app. Once the SC VM is up and running, you could use some form of IPC to have the command line app communicate with the VM, like a fifo or unix domain socket... Maybe it is more hassle than it's worth? I dunno, but I would really love it if I could actually use SC from the command line and use vim to code it... Just some what-nots... ------------------------------ Date: Mon, 10 Sep 2001 00:58:23 -0500 (CDT) From: "AUDIOSYNTH.COM" <---@---.---> Subject: Re: Some requests... regarding the command line stuff - I am already on that.. more later.. ------------------------------ Date: Mon, 10 Sep 2001 01:15:37 -0500 (CDT) From: "AUDIOSYNTH.COM" <---@---.---> Subject: Symposium Announcement (fwd) - ---------- Forwarded message ---------- Date: 04 Sep 2001 13:39:58 EDT From: Eric Lyon <---@---.---> To: asynth@io.com Subject: Symposium Announcement Hi James, Could you forward this announcement to the SuperCollider list? Thanks! Eric - --- Anouncing a Symposium on Computer Music Software When: October 19, 2001 Where: Dartmouth College, Hanover, New Hampshire In order to facilitate experimental music on computer, many pieces of software have been written since the late 1950s. A central feature of these programs is the expectation that computer musicians will utilize them in unpredictable ways, and possibly extend them as well. A remarkably small percentage of these programs has survived and developed a following. The purpose of the symposium is to bring together creators of successful software for experimental music to examine the success of their programs and underlying creative paradigms, and to look ahead to promising future directions. Guest speakers: Max Mathews (Music V) Gareth Loy (CARL) Barry Vercoe (Csound) Miller Puckette (Max) David Zicarelli (MSP) James McCartney (SuperCollider) The symposium is organized in a series of individual presentations, followed by a panel discussion in which significant audience participation is anticipated. The symposium is free and open to the public. For further information, please contact eric.lyon@dartmouth.edu. Eric Lyon - --- http://arcana.dartmouth.edu/~eric ------------------------------ Date: Mon, 10 Sep 2001 14:39:21 +0100 From: Martin Robinson <---@---.---> Subject: Re: fft2nn hello just spotted this thread... > >>> on 8/23/01 12:36 AM, Arie van Schutterhoef at arsche@xs4all.nl wrote: >>> >>>> Is there a way to use tthe magnitude or >>>> the real of a FFT as discrete values to train >>>> Martin Robinson's Neural Nets? >>>> or to rephrase that: >>>> to convert the real part of the input >>>> spectra to an array? >>> >>> Doing it in SC code would be too slow. You'd need to write C code. I've ported the SC code to C as Max object, which was reasonably trivial. I've been using to map controller data (from a USB steering wheel) to parameter data. And I've got a version that can be trained to recognise nato images, but they need to be fairly small for real-time of course. I don't have time at present to make the similarly trivial adjustments from the Max object to an SC plugin but it's just gone on the list. Regards, Martin ------------------------------ Date: Mon, 10 Sep 2001 16:01:20 +0100 From: Arie van Schutterhoef <---@---.---> Subject: Re: fft2nn Hi Martin, First of all compliments for your NN implementation; they work quite smoothly and reasonably fast. >I've ported the SC code to C as Max object, which was reasonably trivial. - -We want to try to avoid using Max... >I've been using to map controller data (from a USB steering wheel) to >parameter data. And I've got a version that can be trained to recognise nato >images, but they need to be fairly small for real-time of course. - -Also depends how deep your network is. >I don't have time at present to make the similarly trivial adjustments from >the Max object to an SC plugin but it's just gone on the list. - -Parallel trying to doing the fft-to-neural net in SC, we're also working on an implementation in C-code on a SGI workstation. And perhaps later developing it as a plugin for SC3. But we need to see firstly whether that will be necessary. AvS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .................................................................. ^ Arie van Schutterhoef | arsche@xs4all.nl ^_北北北北北北北北北北北盻_""""""""""""""""""""""""""""""""" | ` |Schreck Ensemble http://www.xs4all.nl/~schreck/ | ` |# -laboratory for live electro-acoustic music- # | ` |Tel: 00-31-71-5612287 Fax: 00-31-70-3859268 | *========================================================++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .................................................................. ------------------------------ Date: Mon, 10 Sep 2001 09:16:15 -0600 From: David Cottle <---@---.---> Subject: Re: Symposium Announcement > Max Mathews (Music V) > Gareth Loy (CARL) > Barry Vercoe (Csound) > Miller Puckette (Max) > David Zicarelli (MSP) > James McCartney (SuperCollider) I'm extremely interested in this, but won't be able to attend. I hope someone takes notes and posts them. I will soon be meeting with people at the U of U to discuss their electronic lab. I'm going to do my best to convince them to use SC. But I don't know the all of the programs listed above as well as I should (I've only worked with Csound and a limited amount with Max). Does anyone have enough experience with each one to do a brief side by side comparison? - -- ><><><><><><><><><><><> David Cottle, computer music, contra, cottle@cerlsoundgroup.org It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. Sir Arthur Conan Doyle (1859-1930) ------------------------------ Date: Mon, 10 Sep 2001 12:00:54 -0400 From: "crucial" <---@---.---> Subject: Re: Symposium Announcement >David Cottle, computer music, contra, cottle@cerlsoundgroup.org >> Max Mathews (Music V) >> Gareth Loy (CARL) >> Barry Vercoe (Csound) >> Miller Puckette (Max) >> David Zicarelli (MSP) >> James McCartney (SuperCollider) this list is in order of historical appearance. > But I don't know >the all of the programs listed above as well as I should (I've only worked >with Csound and a limited amount with Max). Does anyone have enough >experience with each one to do a brief side by side comparison? I wouldn't at this point recommend teaching Music V or even Csound. CARL: http://www.crca.ucsd.edu/cmusic/cmusic.html is also of primarily historical interest. Max/MSP is good if the students don't wish to learn programming. If you teach SuperCollider, they will learn useful skills (programming) for the rest of their lives, not just get some sounds up and running. _____(( http://crucial-systems.com _________________))_______ ------------------------------ Date: Mon, 10 Sep 2001 10:37:24 -0600 From: Jeffrey P Shell <---@---.---> Subject: Re: Symposium Announcement On Monday, September 10, 2001, at 09:16 AM, David Cottle wrote: >> Max Mathews (Music V) >> Gareth Loy (CARL) >> Barry Vercoe (Csound) >> Miller Puckette (Max) >> David Zicarelli (MSP) >> James McCartney (SuperCollider) > > I'm extremely interested in this, but won't be able to attend. I hope > someone takes notes and posts them. Yes. At times like this, I miss living on the east coast. > I will soon be meeting with people at the U of U to discuss their > electronic > lab. I'm going to do my best to convince them to use SC. But I > don't know > the all of the programs listed above as well as I should (I've > only worked > with Csound and a limited amount with Max). Does anyone have enough > experience with each one to do a brief side by side comparison? I just moved back to Salt Lake, but have very very little experience with Max, and even less with CSound (and those experiences are built more out of annoyances than with anything resembling productivity). jps, http://euc.cx/ ------------------------------ Date: Mon, 10 Sep 2001 10:48:13 -0600 From: Michael Theodore <---@---.---> Subject: Re: Symposium Announcement > > > I wouldn't at this point recommend teaching Music V or even Csound. > CARL: http://www.crca.ucsd.edu/cmusic/cmusic.html is also of primarily > historical interest. > Max/MSP is good if the students don't wish to learn programming. > If you teach SuperCollider, they will learn useful skills (programming) > for the rest of their lives, not just get some sounds up and running. > > I would agree w. most of this, although I think the "space" unit generator is of more than historical importance. It's a serious raytracing inspired spatialization tool, and I'd love to see something of similar quality available in other environments (max extern, sc plug-in). But I am perhaps a bit biased, having gone to UCSD. BTW, hopefully the anti-computer music forces won't find out about this gathering of luminaries. One nuclear bomb on Hanover and computer music will be set back decades.... - -M ------------------------------ Date: Mon, 10 Sep 2001 13:25:31 -0400 From: Phil C <---@---.---> Subject: Re: Symposium Announcement Thus spake Jeffrey P Shell, on the year of our L*rd Mon, Sep 10, 2001 at 10:37:24AM -0600: > >> Max Mathews (Music V) never used it... > >> Gareth Loy (CARL) never used it... > >> Barry Vercoe (Csound) Csound, for me, is the ancient non-realtime SC. It uses a structured format rather than an object one (the programming language) and is missing some of the key components for a good programming language... Like arrays and associative arrays (dictionaries) and even control structures like while and for (ie .do) ... I find it to be more cryptic and far less friendly than SC ... and its lack of realtime processing in any efficient manner is another serious draw back... > >> Miller Puckette (Max) Max, I think, in and of itself was more or less created for data manipulation and rapid development. It has taken on other aspects now, with nato, which takes advantage of the quicktime api... The current version comes with some new features which makes it pretty versatile and some very interesting features... But Max itself does not do any audio. It is more midi and data manipulation based. > >> David Zicarelli (MSP) MSP is a rather disappointing synthesis environment, in my opinion... It in my experiences has been rather slow and the quality ... not so great... Maybe I was just using it incorrectly? I do not know. After about a year of tinkering with it, I became frustrated by it and eventually moved on to SC... ------------------------------ Date: Mon, 10 Sep 2001 21:48:50 -0700 From: nicolocollinsi <---@---.---> Subject: Reverb class This is a multi-part message in MIME format. - --------------4374D98526DFFBB309EC1047 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I enclose a set of reverbs (for SC 2) presented in a single class that I've been preparing for a while. There are conversions to SuperCollider of work by Eric Lyon and Hans Mikelson from the Csound Book (on Gardner reverbs and a stereo reverb unit), and some basic Schroeder reverbs adapted from Curtis Roads CM Tutorial. This code is released in a spirit of enthusiasm. Apologies if some other people have been working on reverbs and I have not referenced them. But all I ever seem to see in SC examples is the bare 4 allpass in series. I'll also put the files on my academic web site, to be available generally. I will be working on plenty of new classes which I may release later this year (BBCut7, the conversion back to SuperCollider of the Csound bbcut, which works on any source audio, other algo comp algorithms) but I thought it unfair to make you all wait until after ICMC for the Reverb class since I hope you can get use out of it straight away, and I think it's quite stable. Nothing about this class is perfect though- please e-mail any bug reports, or your own adaptations of the work. There are notes in the code and help file to that effect. Perhaps an updated, corrected, hopefully improved version as an Xmas present. Cheers Nick Collins - --------------4374D98526DFFBB309EC1047 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="53436A6D"; name="Reverb.help" Content-Transfer-Encoding: 7bit Content-Description: Unknown Document Content-Disposition: inline; filename="Reverb.help" Reverb Superclass: Object A collection of better quality reverbs for mono input. They take more CPU than simply chaining 4 allpass units. There are adaptions of Csound code by Eric Lyon and Hans Mikelson published in chapters 23 and 24 of the Csound Book (MIT Press, ed. Boulanger), as well as from Curtis Road's Computer Music Tutorial. I've adjusted these algorithms to allow some parameters. Proviso- Any of the methods may have a typo! Also, improvements in the available parameters would be the next step. Anyone who feels like improving this code and reposting, please go ahead. The class itself could be better designed. Class Methods All the reverbs are obtained as class methods that return particular ugen graphs. Gardner reverbs *grsmallroom(in) *grmedroom(in) *grlargeroom(in) Schroeder reverbs *simple(in,stretch1,stretch2) stretch1 for onset delay, stretch2 for decay time *multitap(in,stretch1,stretch2,absorption) absorption is filter cutoff frequency Eric Lyon reverbs *fourallpass(in,stretch) *stereoreverb(in,stretch) will return a stereo signal The following are used internally, but may be useful as well. The allpasses are designed to use parameters looptime (delay) and gain, not decay time. Note that myallpass can be used instead of allpass in the case that the Roads formula for conversion from gain and delay to decay is imprecise (see the code). *myallpass(in,delay,gain) *allpass(in,delay,gain) *nestedallpass(in, delay1,gain1,delay2,gain2) *doublenestedallpass(in, delay1,gain1,delay2,gain2,delay3,gain3) Instance Methods None. Better programming might redesign this class with stretch etc internal params + instance methods to call each type of reverb. Call the class ReverbUnit or something. For now, this is a preliminary release. Examples In normal usage, the user will want to mix some dry signal with wet. Calling the Reverb class reverbs will only get you wet signal! All the reverbs have defaults for every parameter but for input. Stretch always defaults to 1, when you get the parameters exactly as in original implementations. ( { var z; z=Impulse.ar(1,0.4); z+(0.4*Reverb.grlargeroom(z)) }.play ) ( { var z; z=Impulse.ar(1,0.4); Mix.ar([[z,z],0.4*Reverb.stereoreverb(z,1)]) }.play ) Author Nick Collins London released 10/9/01 - --------------4374D98526DFFBB309EC1047 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="53436A6D"; name="Reverb.sc" Content-Transfer-Encoding: 7bit Content-Description: Unknown Document Content-Disposition: inline; filename="Reverb.sc" //adaptations by Nick Collins //Gardner reverbs from Hans Mikelson article 11 Aug 2001 //added schroeder and Eric Lyon reverbs 10/9/01 //a collection of better quality reverbs (for mono input) using //delay networks with feedback, filtering, multitaps //fully implemented conversion of Hans Mikelson's article on the Gardner reverbs in Csound to SuperCollider //presented in the Csound book (ed Boulanger, MIT Press 2000) //implementations of the more general reverbs from the Eric Lyon article preceeding it //speculative Schroeder reverbs with info gleaned from Curtis Roads, CM Tutorial, pp481-482 //to do //there are always more reverbs to convert and create! //parameters to multiply all decay times, delay times for the Gardner reverbs //only works for mono sources. Only have mono buffers in delay lines for Gardner revs Reverb { //my allpass implementation *myallpass { arg in,delay,gain; var out,delayout,delaysamp,buffer; delaysamp= delay*Synth.sampleRate; buffer = Signal.new(delaysamp+(Synth.defaultBlockSize)); delayout = TapN.ar(buffer, delay); out= delayout-(gain*in); DelayWr.ar(buffer, in+(gain*out)); ^out } *allpass { arg in, delay,gain; var decay,loopGain; //formula from Roads pp 478 for comb filters- true also for ap? //time to decay by 60 dB loopGain= 20*(gain.log10); decay= (-60/loopGain)*delay; ^(AllpassN.ar(in,delay,delay,decay)) } *nestedallpass { arg in, delay1,gain1,delay2,gain2; var out,delay1out,delay1samp,buffer; delay1samp= delay1*Synth.sampleRate; buffer= Signal.new(delay1samp+(Synth.defaultBlockSize)); delay1out= TapN.ar(buffer,delay1); out= Reverb.allpass(delay1out,delay2,gain2)- (gain1*in); DelayWr.ar(buffer, in+(gain1*out)); ^out } *doublenestedallpass { arg in, delay1,gain1,delay2,gain2,delay3,gain3; var out,delay1out,delay1samp,buffer; delay1samp= delay1*Synth.sampleRate; buffer= Signal.new(delay1samp+(Synth.defaultBlockSize)); delay1out= TapN.ar(buffer,delay1); out= Reverb.allpass(Reverb.allpass(delay1out,delay2,gain2),delay3,gain3)- (gain1*in); DelayWr.ar(buffer, in+(gain1*out)); ^out } *grsmallroom { arg in; var inflt,out,delay0out,delay0samp,buffer,stage1out,stage2out; inflt= LPF.ar(in,6000); delay0samp= 0.024*Synth.sampleRate; buffer= Signal.new(delay0samp+(Synth.defaultBlockSize)); delay0out= TapN.ar(buffer,0.024); stage1out= Reverb.doublenestedallpass(delay0out,0.035,0.15,0.022,0.25,0.0083,0.3); stage2out= Reverb.nestedallpass(stage1out,0.066,0.08,0.03,0.3); out= 0.5*(stage1out+stage2out); DelayWr.ar(buffer, inflt+(0.5*BPF.ar(0.5*stage2out,1600,0.5))); ^out } *grmedroom { arg in; var inflt,out,sum1,buffer,stage1out,stage2out,stage3out,stage3in,feedback; inflt= LPF.ar(in,6000); buffer= Signal.new((Synth.defaultBlockSize)+1000); sum1= TapN.ar(buffer,0.005); //must be at least BlockSize+1 delay stage1out= Reverb.doublenestedallpass(sum1,0.035,0.25,0.0083,0.35,0.022,0.45); //delays and single allpass stage2out= DelayN.ar(Reverb.allpass(DelayN.ar(stage1out,0.005,0.005),0.03,0.45),0.067,0.067); stage3in= (0.4*DelayN.ar(stage2out,0.015,0.015))+inflt; stage3out= Reverb.nestedallpass(stage3in,0.039,0.25,0.0098,0.35); feedback= BPF.ar(DelayN.ar(stage3out,0.108,0.108,0.4),1000,0.5,0.5); out= 0.5*(stage1out+stage2out+stage3out); DelayWr.ar(buffer, inflt+feedback); ^out } *grlargeroom { arg in; var inflt,out,sum1,buffer,stage1out,stage2out,stage3out,stage3in,feedback; inflt= LPF.ar(in,4000); buffer= Signal.new((Synth.defaultBlockSize)+1000); sum1= TapN.ar(buffer,0.005); //must be at least BlockSize+1 delay stage1out=DelayN.ar(Reverb.allpass(Reverb.allpass(sum1,0.008,0.3),0.012,0.3),0.004,0.004); stage2out= DelayN.ar(Reverb.nestedallpass(DelayN.ar(stage1out,0.017,0.017),0.087,0.5,0.062,0.25),0.031,0.031); stage3out= Reverb.doublenestedallpass(DelayN.ar(stage2out,0.003,0.003),0.12,0.5,0.076,0.25,0.03,0.25); feedback= BPF.ar(0.5*stage3out,1000,0.5,0.5); out= 1.5*stage1out+(0.8*(stage2out+stage3out)); DelayWr.ar(buffer, inflt+feedback); ^out } ///4 comb followed by 2 allpass- basic Schroeder reverb //see Curtis Roads CM Tutorial pp 481 //relatively prime delay times //order 10 mS small room- stretch1= 0.2 //50 mS large- stretch1=1 *simple { arg in,stretch1=1.0,stretch2=1.0; var out,combdelays,combdecays; combdelays=stretch1*([0.0499,0.0431,0.0373,0.0311]); //coprime delay times combdecays= stretch2*[1,1,1,1]; out=Mix.arFill(4,{arg i; CombN.ar(in,combdelays.at(i),combdelays.at(i),combdecays.at(i),0.25)}); //allpass in series 2.do({ arg i; out= AllpassN.ar(out,0.01,[0.005,0.004].at(i),[0.05,0.07].at(i)); }); ^out } //pp482, later Schroeder design, Lowpassed TRD + MultiTap early reflections //can easily add extra parameters to control the early reflections *multitap { arg in,stretch1=1.0,stretch2=1.0,absorption=3000; var out,combdelays,combdecays; var early,earlyamps,earlydelays; combdelays=stretch1*([0.0691,0.0617,0.0557,0.0521]); //coprime delay times combdecays= stretch2*[1,1,1,1]; earlydelays=stretch1*([ 0.0311, 0.0349, 0.0373, 0.0409, 0.0431, 0.0449, 0.0499 ]); //coprime delay times earlyamps= Array.geom(7,0.5,0.4); out=Mix.arFill(4,{arg i; CombN.ar(in,combdelays.at(i),combdelays.at(i),combdecays.at(i),0.25)}); //allpass in series 2.do({ arg i; out= AllpassN.ar(out,0.01,[0.005,0.004].at(i),[0.05,0.07].at(i)); }); early= MultiTap.ar(`earlydelays,`earlyamps,in); ^(early+ LPF.ar(out,absorption)) } //eric lyon 1, similar to Schroeder fig 11.21(a) in Roads pp481 //4 allpass in series with filtered branches *fourallpass { arg in,istretch=1.0; var apout,revtimes,output; istretch= istretch/3; output=in; revtimes= istretch*[0.2,0.5,2.1,3.06]; apout= [in,1,1,1,1]; 4.do({arg i; apout.put(i+1,AllpassN.ar(apout.at(i),0.1,[0.04,0.09653,0.065,0.043].at(i),revtimes.at(i))); }); 4.do( { arg i; output = output+ (LPF.ar(apout.at(i+1),[5000,3000,1500,500].at(i),1.0));} ); ^output } //ericlyon2 //decorrelated stereo reverb constructed from allpass, comb, delay and filter units *stereoreverb { arg in,stretch=1.0; var aleft,aright,kdel1,addl1,afeed1,kdel2,afeed2; var aglobrev,aglobin,atap1,atap2,atap3; var kdel3,kdel4,afeed3,afeed4; aleft= AllpassN.ar(AllpassN.ar(in,0.1,0.1,1.7*stretch),0.07,0.07,1.01*stretch); aright=AllpassN.ar(AllpassN.ar(in,0.2,0.2,1.5*stretch),0.05,0.05,1.33*stretch); //original design chooses a new tap every 1 second, with interpolation between values kdel1 = Plug.kr(0.1+(0.01.rand2)); thisSynth.repeat(1.0, 1.0, { kdel1.line(0.1+(0.01.rand2),1.0); //source=0.1+(0.01.rand2) }); afeed1= (0.5*aleft)+ DelayN.ar(aleft,0.2,kdel1); //original design chooses a new tap every 0.95 seconds kdel2 = Plug.kr(0.1+(0.01.rand2)); thisSynth.repeat(0.95, 0.95, { kdel2.line(0.1+(0.01.rand2),0.95) }); //kdel2= 0.1+(0.01.rand); afeed2= (0.5*aright)+ DelayN.ar(aright,0.2,kdel2); aglobin= (afeed1+afeed2)*0.5; atap1= CombN.ar(aglobin,0.15,0.1,3.3*stretch); atap2=CombN.ar(aglobin,0.05,0.0434783,3.3*stretch); atap3=CombN.ar(aglobin,0.03,0.0243902,3.3*stretch); aglobrev=LPF.ar(AllpassN.ar(Mix.ar([atap1,atap2,atap3]),0.085,0.085,2.6*stretch),3000); kdel3 = Plug.kr(0.05+(0.003.rand2)); thisSynth.repeat(1.0, 1.0, { kdel3.line(0.05+(0.003.rand2),1.0); }); afeed3= DelayN.ar(aglobrev,0.1,kdel3); kdel4 = Plug.kr(0.05+(0.03.rand2)); thisSynth.repeat(1, 1, { kdel4.line(0.05+(0.003.rand2),1) }); afeed4= DelayN.ar(aglobrev,0.1,kdel4); ^[afeed3+afeed1,afeed4+afeed2] } } - --------------4374D98526DFFBB309EC1047-- ------------------------------ End of sc-users-digest V1 #354 ******************************